Iranetsol Blog

Squid - قسمت اول

خوب راستش خیلی وقت پیشها در اینجا قول دادم که در مورد نحوه نصب و 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 استفاده کنید .