راستش اولش که تصمیم گرفتم این سایت sarkhat.com/bam رو درست کنم اصلا فکر نمی کردم که اینقدر به درد بخوره . جدا از محبت دوستان وبلاگ نویس که برای معرفی اون خیلی زحمت کشیدن ، خیلی ها بهم نامه زدن و کلی بهم حال دادن ! باور کنید کار 1 ساعت بود و خیلی هم سخت نبود :) اینو همه PHP کارا می دونن . اما خوشحالم که کارم مفید بوده .
بعد از اینکه من یه بانک اطلاعاتی جمع و جور از اطلاعات جسته گریخته اینور اونور جمع کردم ، این سیل کمک و اطلاعات بود که از زمین و هوا می بارید و من که باید وقت می گذاشتم اینا تبدیل می کردم و وارد بانک اطلاعاتی می کردم . اینجاست که آدم می گه خدا پدر و مادر سازنده Perl و MySQL و بیامرزه که کار رو آسون کردن .
بعد شدیم دوتا ! یعنی علی پرورش هم اضافه شد و اون یک دامنه جدید به اسم iranemdad.com رو تهیه کرد و تصمیم گرفتیم به اون آدرس هم منتقل کنیم اطلاعات رو . علی خیلی حرفه ای خبر ها و اسامی جدید را رو هوا میزد و می داد به من که به بانک اطلاعاتی اضافه کنم . در ضمن یه کار جالبی هم کرده که یه تعداد زیادی از عکسهای قربانیان این حادثه رو پیدا کرده که احمد قراره به یه ترتیبی قابل رویت کنه اونها رو برای بازدید عموم و شناسائی قربانیان در سایت ایران امداد قرار بده . رو هم رفته کار خوبی شد ، بهتر از اونی که فکر می کردم . دوستان گردونی هم در زیبا کردن قالبش خیلی کمک کردند . در ضمن کار زیبانی JraNil عزیز هم خیلی تر و تمیز و به موقع بود . دست همه دوستان درد نکنه .
حرف از ایده شد ، یاد مسعود افتادم که با سرگذشتی شبیه به ارشمیدوس ( البته اون انگار تو حموم بوده ، مسعود تو رختخواب ) یه ایده جالب برای استفاده از ErrorDocument و امکانات انتخابی کردن آن توسط apache جهت درست کردن یک پروژه قشنگ فرهنگ انگلیسی به فارسی استفاده کرده . خودتون برید در اینجا و ماجرا رو بخونید .
راستش امروز رفتم خون بدم دیدم اینقدر شلوغه که به من اصلا نمی رسه ! در نتیجه گفتم چه فایده داره که همه یه طور فکر کنند و کمک کنند ! همش خون لازم ندارند که :) خلاصه به فکر افتادم یه طوری مرتبط با حرفه ام بتونم بهشون کمک کنم . این شد که دیدم سایت behpardaz.com که مربوط به اطلاع رسانی برای مجروحان و صدمه دیدگان هستش خیلی وضعش خرابه و اصلا درست Load نمی شه و اصلا هم امکاناتی نداره . سعی کردم هر طور شده یه هر مقدار از اطلاعاتش رو که شده استخراج کنم و اون ها رو کمی مرتب کنم و امکان جستجو و اینا ( البته خیلی ابتدایی و سریع ) بهش بدم و در آدرس http://www.sarkhat.com/bam قرار دادم . نمی دونم اصلا به درد بخوره یا نه ! اما کمک برای یه نفر هم باشه برای من کافیه .
اگر کسی این تولید کنندگان اطلاعات سایت behpardaz.com رو می شناسه بهشون بگه من یه همچین چیزی درست کردم و اگه یه نسخه از اطلاعاتشون برای من هم بفرستن می تونم اطلاعات را کامل بگذارم و امکانات دیگری هم لازم داشتند بهش اضافه کنم . البته براشون email هم زدم ! اما نمی دونم به دست کسی برسه یا نه .
خیلی وحشتناک بود این زلزله ای که توی شهر بم اومده و واقعا تصاویری که شبکه خبر نشون می داد تکان دهنده بود . با اینکه کاری از دستم بر نمیاد اما خوشحالم که هنوز واکسن نزدم و فردا حتما میرم و خون میدم برای مردم حادثه دیده ! این دیگه کمترین کاری هستش که از دستم بر میاد و امیدوارم هر چه زودتر مردمی که زیر آوار هستند پیدا بشن و اگر هنوز زنده هستند ، بتونن به زندگیشون ادامه بدن .
خوب راستش خیلی وقت پیشها در اینجا قول دادم که در مورد نحوه نصب و Optimize کردن Squid در شبکه توضیح بدم . راستش رو بخواهید بسیار بحث طولانی و نفس گیری هستش و کلی هم حال و حوصله تایپ کردن می خواد . نمی دونم بدرد چند نفر می خوره ، اما یه چند نفری هم Comment گذاشتن و هم Email زدن که زودتر این بحث رو شروع کنم . از اونجایی که یه حرفی زدم و حالا توش موندم و حالش رو ندارم ، از ابتدا شروع می کنم و یه قسمت در مورد Hardware ای که می خواهید برای Cache Server انتخاب کنید می نویسم . اگر دیدم واقعا به درد کسی می خوره و جذاب هستش ادامه اش رو هم میریم .
انتخاب سخت افزار مناسب برای یک Cache Server
مقدمه بحث
در ابتدا باید بدونید که عمل Caching بر خلاف خیلی از کارهای دیگه در شبکه به Hardware حساس هست تا به Software . در حقیقت شما بهینه سازی هایی که با انتخاب درست یک Hardware می تونید بکنید خیلی بیشتر و موثرتر از بهینه سازی های نرم افزاری هستش . گویی که در Load بالا همین بهینه سازی های نرم افزاری می تونه باعث بشه به صورت خیلی محسوسی شما از همان Hardware ها به نحو احسن استفاده کنید ، اما انتخاب Hardware رکن اساسی هستش . پس خیلی در مورد خرید Hardware برای Cache Server تون دقت کنید . گاهی پول زیاد دادن و دستگاههای گران قیمت خریدن نه تنها باعث بهبود نمیشه ، بلکه گاهی مشکل ساز هم میشه . پس دقت کنید که در این مورد به خصوص گرونترین ها رو نرید تو بازار انتخاب کنید و با معیار های علمی که اشاره خواهم کرد قطعات مورد نیازتون رو خریداری و انتخاب کنید .
چهار عامل به طور کلی در انتخاب سخت افزارها مهم هستند :
1- زمان دسترسی تصادفی بر روی دیسک شما ( ترجمه ای بهتر برای Random Seek Time پیدا نکردم )
2- مقدار حافظه اصلی سیستم شما و سرعت دسترسی به آن ( RAM )
3- سرعت انتقال اطلاعات از دیسک شما به حافظه اصلی ( حالا نمی دونم چه واژه ای برای Throughput بهتره )
4- و در نهایت سرعت پردازنده شما ( CPU )
البته این عواملی که اشاره کردم مستقیما به Cache مربوط هستند . اما عواملی هم وجود دارند که به صورت غیر مستقیم مربوط هستند که هر کسی می تونه اونها را بنا به نیاز خودش پیدا کنه . مثلا در صورتیکه Cache Server در شبکه به عنوان یک عضو حیاتی محسوب میشه استفاده از Failure Redundancy برای خیلی از قطعات می تونه مشکل رو تا حدودی برطرف کنه . مثلا برای Power و یا خود دیسک . اما در حالت عادی اثر مستقیمی بر Cache Server ندارند .
ابتدا استخراج آمار
ببینید همیشه انتخاب شما وابسته به نیاز شماست . در صورتیکه شما در یک شبکه با تعداد درخواست پائین اما حجم تبادل اطلاعات بالا سر و کار دارید یک نوع انتخاب دارید اما در شبکه ای که تعداد درخواست زیاد اما هر کدام تبادل اطلاعات کمی دارند انتخاب متفاوتی دارید . پس ابتدا بشینید برای خودتون حساب کنید که در شلوغترین حالت ممکن شما چه تعداد درخواست در دقیقه خواهید داشت ؟ جواب این سئوال می تونه مشخص کنه که چه تعدادی object در یک دقیقه دریافت خواهد شد و در نهایت یه ایده ای در مورد ترافیک Cache Server به شما خواهد داد .
البته محاسبه بیشترین تعداد درخواست کار ساده ای نیست ، به خصوص اینکه شما هیچ ایده ای در مورد تعداد کاربرانتون و پهنای باند احتمالی که می خواهید بر روی آن کار کنید نداشته باشید . بنابراین شاید در این موارد بهترین کار این باشه که یه دستگاه بدرد نخور پیدا کنید و روش یه دفعه به صورت معمولی یه Cache Server نصب کنید و مقدار ترافیکتون رو توسط منتقل کردن ترافیک تعدادی از کاربرانتون برای مدتی بر روی این دستگاه تخمین بزنید .
دقت کنید در هنگام تخمین زدن از اعدادی که در شلوغترین حالت ممکن بدست می آورید استفاده کنید و از معدل استفاده نکنید . یعنی مثلا تعداد درخواستها در روز رو تقسیم بر 1440 کنید و بگید این مقدار ترافیکتون در دقیقه هستش ! این غلطه ! شما باید شلوغترین ساعتها رو پیدا کنید و بر اساس اونها مقدار تخمینی رو پیدا کنید .
انتخاب دیسک
خیلی موارد هستش که موقع انتخاب و خرید دیسک باید مد نظر قرار بدهید . قبلا در مقدمه اشاره کردیم که موارد مهم در انتخاب دیسک همانا زمان دسترسی تصادفی و سرعت انتقال اطلاعات از آن است . داشتن سریعترین دیسک دنیا همیشه بهترین انتخاب نیست چراکه ممکنه که حجم زیادی از اطلاعات رو نتونه در خودش جا بده . دیسک مناسب برای Cache دیسکی هستش که بتونه حجم معقولی از اطلاعات دریافت شده از Internet رو بر روی خودش قرار بده و در عین حال به اندازه ای سرعت داشته باشد که بر اساس تعداد درخواستهای شما در ثانیه سرعت Browsing شما رو کند نکنه .
مهمترین چیزی که باید در Document های دیسکتان به دنبال آن بگردید عددی است که مشخص کننده Random Seek Time هستش . هر چقدر مقدارش کمتر باشد بهتر است . این عدد مشخص کننده زمانی به میلی ثانیه هستش که هد دیسک اطلاعاتی رو از یک تراک تصادفی به تراکی دیگر منقل می کند . البته یک سیستم عامل قدرتمند همیشه بهترین روش ها رو برای انجام این کار در نظر میگیره و سعی می کنه که این زمان به حداقل برسونه ، اما بالاخره همیشه محدودیت سخت افزاری وجود داره و انتخاب دیسکی که زمان کمی را از این لحاظ داشته باشد می تواند خیلی به سرعت دار شدنCache Server شما کند . دقت کنید که انتظار CPU برای دیسک می تونه خیلی سرعت Cache Server شما رو کاهش بده .
( در آینده خواهم گفت که مثلا استفاده از سیستم عامل هایی که Posix Thread رو پشتیبانی می کنند واجرا کردن Cache به صورت asynchronous Input-Output و البته انتخاب فایل سیستم مناسب می تونه خیلی خوب از قابلیت های یک Hardware خوب برای سرعت بخشیدن به عمل Caching و پشتیبانی از تعداد بالا درخواست در ثانیه کمک کنه، اما فعلا مطمئن بشید که Hardware شما مناسب باشد )
یک Cache با یک دیسک در حالت عادی برای هر درخواست باید یکبار بر روی دیسک جستجو انجام دهد ( فرض کنید که RAM Caching برای دیسک وجود نداشته باشد و لیستی از Object ها نیز در حافظه اصلی نیست ) . در صورتیکه شما فقط یک دیسک دارید فرمولی که برای بدست آوردن تعداد درخواست در ثانیه هست به صورت زیر است :
زمان دسترسی تصادفی / 1000 = تعداد درخواست در ثانیه
البته Squid این قابلیت رو داراست که نوشتن بر روی دیسکها رو در صورت وجود بیش از یک دیسک برای Cache تعدیل کند . بنابراین زیاد کردن تعداد دیسکها باعث پائین آمدن زمان دسترسی تصادفی خواهد شد و در نتیجه بازدهی بهتری خواهید داشت . با اینکه در سیستم عامل های مختلف ممکن است این قضیه مقادیر مختلفی در بر داشته باشه ، اما اگر فرض کنیم شما از دیسکهایی استفاده می کنید که زمان دسترسی تصادفی یکسانی دارند می توانید از معادله زیر برای بدست آوردن تعداد درخواستهای قابل سرویس دهی در ثانیه به ازای تعداد دیسکهای خود استفاده کنید :
( تعداد دیسکها / زمان دسترسی تصادفی ) / 1000 = تعداد درخواست در ثانیه
مثلا اگر فرض کنیم 3 دیسک که هر کدام دارای 12 میلی ثانیه زمان دسترسی تصادفی می باشند برای Cache Server در نظر بگیریم بر اساس معادله بالا : (3/12)/1000 = 250 عدد درخواست در ثانیه را به خوبی می توانیم توسط این Cache Server جوابگو باشیم .
نکته دیگری رو که باید در اینجا اشاره کنیم در مورد انتخاب IDE و SCSI هستش . ببینید واقعش اینه که این روزا اینقدر IDE ها پیشرفت کرده اند که زمان دسترسی تصادفی مشابهی با SCSI ها پیدا کرده اند ( البته IDE هایی که از DMA-Compatible Controllers استفاده می کنند ) . بنابراین با تفاوت قیمت فاحشی که دارند برای کسانی که تعداد زیادی درخواست دارند و هر کدام سرعت کمی در انتفال اطلاعات دارند ( دقیقا چیزی که ISP ها به آن نیاز دارند ، یعنی تعداد درخواست بالا ، اما هر کدام بیش از 56 کیلوبیت در ثانیه امکان دریافت و ارسال اطلاعات ندارند ) استفاده از IDE های با زمان دسترسی تصادفی مناسب خیلی به صرفه تر هستش براشون . البته کسانی که از Object Size های بالا برای Caching استفاده می کنند ( یعنی Object های حجیم رو می خواهند Cache شود ) و کاربرانشان دسترسی های پر سرعت به شبکه دارند ( مانند کاربران یک شبکه محلی که Download های زیاد دارند ) استفاده از SCSI که دارای سرعت انتقال اطلاعات به مراتب بالاتری می باشد مناسبتر است .
در مورد حجم دیسک مربوط به Cache شما تصمیم گیری کمی مشکل است . ببینید برای چند نفر کاربر محدود که در یک شرکت هستند شاید در حد 100 مگابایت مقدار مناسبی باشد . ( در صورتیکه کارای عجیب غریبی نکنند و سرعت ارتباطی اونها معقول باشد مانند 64K ) . اما برای Production Use و یا استفاده از شبکه های با هدف خاص ( مانند ISP ها برای کابران Dial-up ) قضیه کمی پیچیده تر هستش . در حقیقت این مقدار بستگی به چندین فاکتور داره .
فرض کنید که شما می خواهید یک Cache Server برای خودتون توی خونه راه بندازید . اگر شما 1 گیگابایت فضا برای Cache Server خودتون اختصاص بدهید و به صورت متوسط 10 مگابایت اطلاعات را در روز Browse کنید ، حداقل 100 روز طول میکشه که Cache شما پر شود . بنابراین شاید خیلی زمان زیادی طول بکشد که واقعا Cache Server شما به HIT Rate واقعی برسد ( HIT Rate یعنی نسبت تعداد درخواستهایی که از Cache سرویس داده می شود نسبت به کل تعداد درخواستها ) . از اونطرف اگر مثلا اگر 10 مگابایت دیسک برای یک Cache Server اختصاص بدهید و مثلا 10 درخواست در ثانیه داشته باشد این Cache Server شما خواهید دید که Object هایی که در Cache شما می مانند برای چند ساعت هم نخواهند بود و این باعث می شود که عملا شما HIT Rate ای نداشته باشید . بنابراین برای اینکه مقدار واقعی و بدرد بخوری برای اندازه دیسک Cache خود پیدا کنید باید حدودا بدانید که چه مقدار اطلاعات از Cache Server عبور خواهد کرد در طول روز . در صورتیکه ایده ای از این مقدار ندارید می توانید پهنای باند خط ارتباطی خود به اینترنت رو ملاک قرار دهید . مثلا 1MB/Sec خط اینترنت ( سعی می کنم مثالهام رو منطبق با شرایط ISP ها مطرح کنم ، چون عملا بیشترین کاربرد Cache Server برای ISP ها و برای End-User های هستش ) در حدود 125000 بایت اطلاعات را می تواند در یک ثانیه منتقل کند . اگر همه کاربران این خط اینترنت قرار باشد از Cache Server استفاده کنند ، بنابراین دیسک این Cache Server در هر ثانیه 125K پر می شود که می کنه به عبارتی 450 مگابایت در هر ساعت . حالا اگر تمام ساعات شبانه روز این خط استفاده شود چیزی در حدود 3.6 گیگابایت اطلاعات را می تواند جابجا کند . چون معمولا همچین چیزی نیست که همه خط در طول شبانه روز 100% استفاده شود فرض می کنیم به طور متوسط 2 گیگابایت تبادل اطلاعات با Internet از طریق این Cache Server بشود . بنابراین شما دیسکی با حجم 2GB لازم دارید تا بتوانید اطلاعا ت یک روز به طور کامل نگهداری کنید . حالا در صورتیکه بسته به نظر شما می خواهید تعداد روزهای بیشتری رو نگهداری کنید می توانید این مقدار رو زیاد کنید . من فکر می کنم به طور متوسط نگهداری اطلاعات 1 هفته مقدار مناسبی است . بنابراین 14 گیگابایت مقدار مناسبی برای این حجم ترافیک خواهد بود . مهم اینه که شما ایده قضیه رو بگیرید و خودتون در اشل کاری خودتون پیاده کنید و با نیازهاتون مقدار مورد نیازتون رو پیدا کنید .
در ضمن Hit Rate بستگی به تعداد سایتهایی که کاربران شما مشترکا از آنها بازدید می کنند داره . اگر فکر می کنید که کاربران شما در زمینه خاصی از سایتهایی که دارای اطلاعات حجیم هستند مشغول به فعالیت هستند ، این عامل را هم در انتخاب حجم دیسک حتما دخیل کنید .
البته بعضی هم از RAID برای Cache Server های خودشون استفاده می کنند . این هم از روشهایی هستش که می تونه به طرز خارق العاده ای Performance شما را بالا ببره . البته دقت در انتخاب نوع RAID ای که استفاده می کنید مطمئنا مهمه . استفاده از RAID-0 می تونه سرعت کار شما به شدت بالا ببره ، چون در حقیقت همان زمان دسترسی تصادفی رو کاهش میده ، اما در صورتیکه Stability برای شما مهمتره می تونید از RAID-5 استفاده کنید که در صورت ایراد در یکی از دیسک ها بقیه وظیفه اش رو جبران کنند و ضرری به کاربران نرسد .
در نهایت به شخصه به این تجربه دست پیدا کرده ام که استفاده از تعداد زیادتری دیسک معمولی و کم ظرفیت که زمان دسترسی تصادفی خوبی دارند ، بهترین انتخاب هستش و خرج کمتری هم نسبت به روش های نوین مانند RAID و دیسکهای پرسرعت و گرون قیمت داره .
انتخاب حافظه اصلی ( RAM )
Squid یک جدول از لیست Object هایی که بر روی دیسک داره بر روی حافظه اصلی نگهداری می کنه . به این دلیل که این لیست به ازای هر درخواست باید جستجو روش انجام بشه باید دسترسی سریعی بهش وجود داشته باشه و اصلا به همین خاطر هستش که همه اش در حافظه اصلی قرار دارد . بنابراین باید مقدار حافظه اصلی رو طوری انتخاب کنید که سیستم عامل به دلیل حجیم بودن این جدول و کم بودن حافظه اصلی مجبور نشود مقداری از آن را داخل حافظه مجازی در Swap قرار دهد . این کار باعث می شود که سرعت جستجو در این جدول به شدت کاهش یابد و در نهایت تعداد درخواست کمتری را در ثانیه قادر به پاسخگویی باشید .
هر کدام از Object هایی که بر روی دیسک قرار دارند در حدود 75 بایت فضا در حافظه اصلی درون این جدول را اشغال می کنند . بنابراین در صورتیکه شما 8 گیگابایت دیسک برای Caching داشته باشید چیزی در حدود 48 مگابایت RAM برای نگهداری اطلاعات این جدول لازم است که باید مقدار حافظه ای که برای بار شدن سیستم عامل و برنامه های دیگر راه انداز لازم است را نیز به آن اضافه کنید .
در ضمن انتخاب نوع حافظه اصلی نیز می تونه تعیین کننده باشه . مثلا استفاده از RAM های DDR که سرعت انتفال خیلی بیشتری را دارا هستند می تواند خیلی کمک کند که جستجو درون جدول سریع شود و در نهایت تعداد زیادتری درخواست رو سرویس دهی کند .
انتخاب CPU
کلا Squid و عمل Caching خیلی به CPU حساس نیستند . ممکنه در ابتدا که Squid بالا می آید و می خواهد همان لیست کذایی رو در حافظه اصلی ایجاد کند Process سنگینی انجام دهد ، اما این نهایتا مال چند دقیقه خواهد بود و بعد از آن CPU همیشه منتظر IO خواهد بود . بنابراین اصولا خیلی Load بالایی برای CPU نخواهید داشت . مثلا یک Pentium 133 می تونه خیلی راحت چیزی در حدود 7 درخواست در ثانیه رو بدون هیچ مشکلی سرویس دهی کند . بنابراین پول زیادی برای تهیه CPU های پرسرعت و گران قیمت برای Cache Server ندهید و به CPU هایی که معمول بازار هستند و قیمت مناسبتری دارند اکتفا کنید . مثلا در این زمینه AMD فکر می کنم قیمت های مناسبتری نسبت به Intel داره .
در ضمن استفاده از Motherboard های که قابلیت استفاده از چند CPU همزمان را دارا هستند هم طبیعتا کمک شایانی نمی کند . چرا که SMP و استفاده از چند CPU موقعی به درد می خوره که شما Load بالایی داشته باشید و تعداد Task های زیادی هم داشته باشید . در اینجا شما اصل کارتون توسط یک Task مربوط به Squid انجام می شود و همان هم چندان کار CPU ای زیادی ندارد . گویی که استفاده از Async-IO که بعدا توضیح می دهم تعداد زیادی thread را ایجاد خواهد کرد ، اما Load آنها هم آنچنان زیاد نیست که بخواهید از چندین CPU استفاده کنید .
سعي مي کنم که خيلي کوتاه و سريع مواردي رو که بايد هنگام Upgrade کردن سيستم هاي قديمي به Kernel جديد مد نظر قرار بديد ، را بيان کنم . اميدوارم که به درد بخوره :
1- اول از همه اينکه چون نسخه هاي اوليه اين نسخه از کرنل هستش هميشه موقع نصب کرنل سعي کنيد که نسخه آخري که ارائه شده رو دريافت کنيد . در اوايل کار خيلي زود نسخه عوض مي کنه و خيلي ايراد ها تند تند رفع مي شوند .
2- قبل از Upgrade از Config فايلهاي مهم و اطلاعات حياتي حتما Backup برداريد . گاهي اوقات Incompatible بودن فايل سيستم در کرنل جديدي که ساختيد ممکنه باعث دردسر بشه . ( بخصوص براي اونايي که از ReiserFS و JFS استفاده مي کنند )
3- دقت کنيد که برنامه هاي زير که آمده همگي نسخه حداقل که جلويش آمده است را داشته باشه . ممکنه به مشکل برخورد کنيد در غير اين صورت :
4- بنا به File System اي که استفاده مي کنيد هر يک از برنامه هاي مربوطه اش را با نسخه حداقل تطابق دهيد :
5- در صورتيکه از هر يک از امکانات زير علاوه بر امکانات معمول استفاده مي کنيد نسخه نرم افزارهاي مربوطه را با نسخه حداقل مطابقت دهيد :
6- در صورتيکه واقعا مي دانيد چه چيزهايي را لازم داريد و چکار داريد مي کنيد برويد و make menuconfig يا اگر از Xwindow استفاده مي کنيد make XConfig را استفاده کنيد و امکاناتي که لازم داريد در کرنل فعال کنيد . در غير اين صورت پيشنهاد مي کنم يا اينجا را مطالعه کنيد و يا بر روي يک دستگاه که برايتان مهم نيست امتحان کنيد و امکانات مورد نياز خود را پيدا کنيد .
7- در اين نسخه از کرنل نيازي به ساختن Dependency ديگر نداريد و مي توان يک ضرب make install کنيد . يادتان نرود در صورتي که امکاني را به صورت module تعريف کرده ايد make modules modules_install را بزنيد حتما .
8- پيشنهاد مي کنم در مرحله آخر boot loader خود را طوري تنظيم کنيد که در ابتدا از شما سئوال کند که با کدام kernel مي خواهيد boot شود که در صورت بروز مشکل بتوانيد با kernel قبلي برگرديد و مشکل را حل کنيد .
اميدوارم از امکانات kernel جديد لذت ببريد و به مشکلي هم بر نخوريد .
خوب به نظر منم Fedora با اینکه در حقیقت نسخه اول با این نام است و انتظار می رود که ایراد زیاد داشته باشد ( در حقیقت فکر می کردم یه چیزی تو مایه های Redhat 7.0 و یا 8.0 باشه ) اما خیلی خوب و کامل و در عین حال بی عیب در زمینه Networking ظاهر شده .
من در حدود 2 هفته هستش که در 2 جای مختلف و برای 2 منظور مختلف که البته هر دو در ارتباط با Network هستند دارم ازش استفاده می کنم و البته زیر بار هم هستش و تقریبا هیچ مشکلی باهاش نداشتم .
از جمله خصوصیات خیلی خوبش در زمینه Networking میشه به پشتیبانی پیش فرض از 802.1q VLAN و پشتیبانی از تمامی Module های جدید و بدرد بخور Netfilter اشاره کرد . کرنل پیش فرض Fedora خیلی خوب امکانات Networking رو بدون ایراد در اختیار شما می گذاره و بر خلاف RedHat 9.0 که برای کار همیشه مجبور بودم یه دفعه Kernel رو بگیرم و دوباره برای کار خودم Compile کنم در اینجا اصولا نیازی به این کار نیست . البته این Redhat 9.0 دوباره Compile کردن Kernel روش خودش کلی مشکل داشت . به هر صورت به نظر من همه نسخه های x.0 مربوط به RedHat برای کار Networking به درد نخور هستند و این خیلی خوبه که Fedora از همین اول اینقدر خوب در زمینه Networking ظاهر شده . تا قبل از این من نسخه RedHat 7.3 را از همه نسخه های دیگرش بیشتر ترجیح میدادم .
خوب بالاخره این کرنل 2.6 هم در آمد . من راستش دریافت کردمش اما هنوز وقت نکردم که نصبش کنم . اما مسعود در این مطلب در وبلاگش در مورد تجربیاتش در مورد چند ساعت کار کردن با این Kernel نوشته . به نظر میاد در خیلی زمینه ها پیشرفت کرده . در مورد پیشرفت هاش می تونید عمده تغییراتش رو در این مقاله ببینید .
فکر کنم به زودی بتونم نصبش کنم و در مورد پیشرفتهای قابل ملاحظه ای که در زمینه Networking کرده مطلبی بنویسم . حواستون باشه که اگر می خواهید Upgrade کنید حتما از نسخه های Compatible با این نسخه استفاده کنید . من خودم روی Fedora Core 1 نصب خواهم کرد اما به نظر میاد Slackware 9.1 هم سازگار با این Kernel هستش . Fedora Core 2 هم به زودی با این حساب با همین نسخه جدید کرنل در خواهد آمد منتظرش باشید .
مجله Linux Journal در یک نظرسنجی از خوانندگان خودش که معمولا Linux کارها و علاقمندان به این سیستم عامل هستند برنامه ها و نرم افزارها و توزیع کنندگان محبوب در لینوکس رو جویا شده که نتایجش رو می تونید از اینجا ببنید .
چیزایی که به نظر من هم واقعا حقشون بوده اینا هستند :
XMMS به عنوان بهترین برنامه پخش صدا
Mozilla به عنوان بهترین مرورگر اینترنتی
MySQL به عنوان بهترین و محبوبترین سیستم مدیریت بانک اطلاعاتی
Coffee به عنوان بهترین نوشیدنی هنگام برنامه نویسی :)
GIMP به عنوان بهترین برنامه گرافیکی
++C به عنوان محبوبترین زبان برنامه نویسی ( در بهترین بودنش شکی نیست :) )
AMD Athlon به عنوان بهترین Processor
VIM به عنوان بهترین و محبوبترین Editor ( بدون این Vi زندگی هم سخت شده دیگه برای من ! )
GCC بهترین ابزار توسعه دهنده
SUSE به عنوان بهترین گزینه برای یادگیری
Debian به عنوان بهترین گزینه برای استفاده به عنوان Server و سرویس دهی
KDE به عنوان بهترین رابط گرافیکی
نظر شما چیه ؟!
فکر نمی کنم هیچ ایرانی ای و یا شایدم هیچ آدم مستقلی در دنیا وجود داشته باشه که از دستگیر شدن صدام آن هم با اون وضعیت ناراحت شده باشه ! بلکه برعکس خیلی ها در ایران ( از جمله نسل هم سن و سالای ما که در زیر بمباران نیروهای صدام کودکیشون رو گذروندند ) و در خیلی جاهای دنیا از اینکه بالاخره خیالشون از این موجود خطرناک راحت شده بسیار ابراز شادمانی کردند . در این بین از همه خوشحالتر فکر کنم مردم عراق بودند . به هر حال این مطلب رو بیشتر برای این می نویسم که بعدا وقتی وبلاگم رو مرور می کنم بدونم در چه روزی و چه شرایطی چه اتفاقاتی افتاده . به هر حال اینا هم جزئی از زندگی هستند و همش زندگی من وسط Linux و Cisco و ... نمی گذره که :)
ببینید سعی می کنم غیر واقعی به این مساله نگاه نکنم . اما مطمئنا بازم نظرات شخصی من به این مساله هست و چون کلا به اینترنت و شبکه ( که بخشی از زندگی و حجم بزرگی از کار من رو تشکیل میده ) مربوط میشه فکر می کنم بتونم از خودم در موردش نظر بدم .
خوب راستش رو بخواهید با اصل مساله فیلترینگ موافقم ! اما ایرادی که به وضعیت فعلی می توان گرفت نحوه پیاده سازی آن است . قبلا یه دفعه تلویحا گفتم مشکل من سر این است که مساله فیلترینگ نباید دغدغه اصلی اینترنت ملی ما در کشور بشود . فکر می کنم الان در حدود ماههاست که دغدغه اصلی مسئولان سیاست گذاری اینترنت کشور شده کدام سایت را ببندیم ، کدام را نبندیم ، کدام دستگاه را برای فیلترینگ استفاده کنیم ، کدام مشکل ایجاد می کند و ... + میلیونها و شاید میلیاردها هزینه ای که برای پیاده سازی چنین پروژه ای می شود . قبلا یه دفعه این بحث رو کردم که رفتن از لایه ای از شبکه به لایه بالاتر جهت انجام عمل فیلترینگ شاید برای یک ارتباط خانگی اصلا مشکل و یا هزینه ای در بر نداشته باشد ، اما وقتی از پهنای باندی صحبت می کنید که یک کشور دارد از آن استفاده می کند دیگر به همین راحتی نمی توان این کار را کرد و باید کلی طراحی و مدل سازی شبکه ، ترافیک شبکه و ... و خلاصه وقت و هزینه بگذارید که همچین پروژه ای انجام شود . اینکه می گویند قابل انجام نیست هم مسلما بی خود است ، همه می دونند در بحث Network شما هر کاری که از نظر تئوری منطقی باشد می توانید انجام دهید ، اما همانطور که گفتم بحث من بحث نحوه پیاده سازی این قضیه است .
ببینید اصولا شما از هر چیزی می توانید استفاده درست و نادرست کنید . مهم این است که هر کسی بنا به نیازش بتونه از امکاناتی که در اختیارش هستش استفاده درست کنه . شما از یک بادمجون !!! ( از این بی ربط تر پیدا نکردم ) هم می توانید استفاده درست کنید ( یه چیزی تو مایه های خورش کدو بادمجون ) و هم می توانید استفاده بد و یا حتی خطرناک کنید ( از بادمجون چه استفاده نا مشروعی میشه کرد ؟! :) مطمئنم که هر کس یه مورد استفاده بسته به نیازش براش پیدا می کنه :) ) اما به صرف این قضیه که چون می توان از آن استفاده نا مشروع کرد پس نتیجه بگیریم که باید آنرا ممنوع کرد ، مسلما از نظرهر کسی غلط است . 1001 دلیل موجه هم می توان برای اینکار آورد که مثلا تا وقتی با بادمجون میشه این همه چیزای خوشمزه درست کرد چه دلیل داره که آدم کار نامشروع یا غیر معقول ( مثل بادمجون واکس زدن :) ) باهاش انجام بده و یا با این قیمتهای امروزی کیه که بره بادمجون بخره و نخورتش ، اما هر کاری کنید همه مدل آدمی پیدا میشه و هر استفاده ای ممکنه ازش بشه کرد . اما کسی نمیاد آنرا کنترل کند و به خاطر یک عده قلیل ، یه عده زیادی رو به دردسر نمی اندازند که از داشتن خورش کدو بادمجون محروم بشن :)
به هر حال این یک مثال بود ( که کمی هم غیر واقعی بود ! اما مسلما منظور من رو میرسونه ) . حرفم اینه که بحث فیلترینگ درسته اما اجرای اون توسط آموزش به خانواده ها به راحتی قابل انجامه . اگر واقعا خانواده ای نگران تهدیدات منفی اینترنت ( که واقعا هم وجود داره ) برای فرزندان خود باشد مسلما با گذاشتن چند راه حل ساده در مقابلش می شه این نگرانی رو براش برطرف کرد . اگه کمی عملی به قضیه نگاه کنیم می تواند چندین راه حل داشته باشد . مثلا همین ابزاری ( Content Advisor ) که IE و چندین Browser پرقدرت دیگر برای محدود کردن دسترسی به سایتها بر روی هر کامپیوتر دارد ( کمتر کسی را دیده ام که حتی از این ابزار یک دفعه هم استفاده کند ) یا تهیه نرم افزارهایی برای انجام این منظور توسط خود خانواده ها و چندین و چند راه دیگه که مطمئنا اونایی که نظریه فیلترینگ رو میدن از من بهتر بلدن . با چنین راه حلهای ساده ای هم چنین خرج عظیمی را نکرده ایم و هم خیلی کاربردی تر به مساله نگاه کرده ایم . صد البته که هیچ کدام از این راه هایی که پیشنهاد داده بشه 100% نیست و اصلا کدام راه حل است که 100% مشکل را حل کند ؟! اصلا همین فیلترینگ فعلی مخابرات چند درصد مشکل را حل می کند ؟!
به نظر من مشکل اصلی اینه که راهی برای افرادی که نگران بستگان و یا فرزندان خود ( یا هر شکل دیگرش مثل کارفرمایی که نگران کارمندانش است که نمی خواهد وقتشان را سر کار بر سر chat و امثالهم صرف کنند ) وجود داشته باشد که بتواند مشکلشان را خودشان حل کنند . و الا هر کسی که چند ساعت با Internet کار کند می تواند 1001 روش برای دور زدن همین سیستم فیلترینگ جدید و پر قدرت مخابرات پیدا کند . گویی که اصلا همین فیلتر باعث شده فکر و ذهن خیلی ها بجای 1000 تا مشکل دیگه به دور زدن و دوباره کاری های این چنینی صرف بشه . این مدل فیلترینگ باعث میشه که سایتهایی که فیلتر می شوند اگر تا بحال مورد توجه خیلی ها واقع نمی شدند از این به بعد مورد توجه قرار بگیرند ، نه به این علت که علاقه ای به خیلی از آنها داشته باشند بلکه صرفا به دلیل : " الاِنسانُُ حََریصٌٌ عَلی ما مُنِِع ! " . ( بابا یونیکد )
به هر حال باز هم می گم این حرفایی که من میزنم صرفا نظرات شخصی من در حوزه مساله ای هستش که واقعا به کارم مربوط میشه و مطمئنا نقص ها و شایدم اشتباهاتی داشته باشه که با دیدن نظرات دوستان به اونها پی ببرم .
همونطوری که می دونید iptables و کلا Netfilter در Layer 3 یعنی لایه شبکه و زیر شبکه فعالیت می کنند . خوب خیلی امکانات زیادی در این لایه در اختیار شما می گذارند . اما یه نکته را هیچ موقع فراموش نکنید ، اونم اینکه هر چقدر برنامه شما در لایه بالاتری اجرا شود هم CPU Load بیشتری می گیرد و هم Memory بالاتری را استفاده می کند و در نهایت پهنای باند کمتری می تواند سرویس دهی کند . در حقیقت اگر پهنای باند شما خیلی زیاد باشد باید Load Balancing رو چند تا ماشین داشته باشید که خوب مسلما نیاز به هزینه بالاتری دارد . گویی که خیلی مواقع راه چاره دیگری نیست ( چرا که خیلی مواقع نیاز به rule هایی دارید که از خواص لایه 3 استفاده می کند ) اما در خیلی از موارد نیز می توان راه چاره دیگری جست ! در حقیقت اگر شما کنترل Packet ها رو به لایه 2 ببرید کلی CPU Usage و Memory صرفه جویی می شود و به همین دلیل پهنای باند بیشتری می توان سرویس دهی کرد .
در Linux یه پروژه ای به راه افتاده به نام ebtables که در حقیقت همتای iptables در Ethernet Bridge هستش . ( مخفف Ethernet Bridge Tables ) این پروژه البته فعلا در کرنل 2.4 به صورت پیش فرض وجود ندارد و باید آنرا patch کنید . اما قرار است که در کرنل 2.6 به صورت پیش فرض امکانش به کرنل اضافه شود .
همونطور که می دونید Bridge ها در لایه 2 فعالیت می کنند و در صورتیکه شما بتوانید دو Interface با هم Bridge کنید می توانید توسط این ebtables بر روی Interface مربوط به Bridge به دلخواه خودتان Rule هایی تعریف کنید . صد البته نمی توانید بر اساس IP و Port و ... که در لایه 3 مشخص می شوند rule تعریف کنید ، اما بر اساس MAC Address های منبع و مقصد ، نوع Protocol مانند IPv4 و IPv6 و ARPA و ... و ... که در راهنمای خودش در سایتش و یا نمونه هایی که آورده می توانید آنها را بخوانید . نکته جالب آن که مطمئنم برای مدیران شبکه که دارند این مطلب را می خوانند جالب است ( که من در Cisco همچین قابلیتی ندیدم ) امکان تعریف NAT در لایه 2 بر اساس MAC می باشد . یک نمونه از این کار در نمونه های خودش هست ! خوبیش اینه که VLAN 802.1q رو هم پشتیبانی می کنه و شما می توانید دو تا sub interface رو با هم Bridge کنید که دیگه محشر میشه :)
به هر حال این یک نمونه ای از پیشرفتهای کرنل در نسخه های جدید آن در زمینه Networking هستش .
نمی دونم تا حالا به این مشکل برخوردید یا نه ؟ من تازگی ها IE م یه مشکلی پیدا کرده که همش این Status Bar پائین صفحه ام بی خود و بی جهت میره !!! حالا هی ما دستی میریم درستش می کنیم باز دوباره خودش میره !! اصلا نمی دونم چه مرگشه ! خلاصه گفتم گور بابای Micro$oft میرم یه Browser دیگه نصب می کنم . خلاصه داشتم می گشتم که به Mozilla Firebird برخوردم . دیدم هم حجمش کمه و هم تازگی ها خیلی ازش صحبت میشه . خلاصه Download ش کردم و دیدم عجب چیزه توپی هستش ! همه امکانات IE رو داره و کلی امکان اضافه و به نظر من خیلی هم از IE سریعتر Page ها رو Load می کنه . ( من هی به خودم گفتم نه بابا خیال می کنم ، اما دوستم هم که اومده بود پیشم و دید همین رو گفت ) خلاصه شمام ببینیدش شاید مشتریش شدید :)
راستی اون ایراد IE رو کسی می دونه به خاطر چیه ؟! برای کس دیگه ای هم پیش اومده ؟!
این Status Bar اون پائین که میره Web برای من مثل اخبار ناشنوایان میشه :) نمی دونم چه مرضیه :)
درسته که کلا خیلیا با بحث فیلترینگ مخالف هستند ( از جمله خودم که معتقدم این بحث نباید در حد اینترنت ملی ما باشد ) ، اما حالا که قرار هست فیلتر وجود داشته باشد لااقل باید بدون مشکل وجود داشته باشد .
من در دو مطلب گذشته ( اینجا و اینجا ) در مورد مشکلات سیستم فیلترینگ جدیدی که مخابرات نصب کرده است توضیح دادم و مشکلات رو مطرح کردم . گویا از مسئولین شبکه مخابرات وبلاگ من رو دیدن و مشکلات رو حل کردند و جوابش را حل به صورت comment برایم گذاشته اند . دستشان درد نکنه . اما چند نکته رو در این زمینه بگم :
1- من منبع خودم در مورد اینکه مخابرات از Linux و Squid و Squidguard برای سیستم فیلترینگ جدید استفاده کرده است سایت ITIran ( در این مطلب ) و در نهایت آقای امید حسینی ( در این مطلب ) معرفی کردم و نوشتم که در صورتیکه فرض رو بر این بگیریم که اینگونه باشد مشکلات بازهم قابل حل است ( چرا که راه حل آنرا نیز نوشتم ) . حال به نظر میاد که این منابع خبر درستی را منتشر نکرده اند و مسئولین شبکه مخابرات می گویند که از نرم افزار Smart Filter که روی NetCache نصب شده است استفاده می کنند . البته مسائلی رو که من مطرح کردم ( مهمترینشون IP Spoofing ) مطمئنا نرم افزارهای تخصصی فیلترینگ ( از جمله همین Smart Filter ) که مخابرات استفاده می کنند ، امکانانتش رو دارند و با تذکری که داده شد مشکل هم حل شد .
2- در مورد تقسیم بار هم نکات جالبی را گفته اند که می توانید در comment های همان مطلب بخونید . گویا فکر تقسیم بارها رو هم کرده اند .