بهینه سازی توزیع سرورها در رک ها

در یکی از چت ها سوالی از من پرسیده شد:

- آیا چیزی وجود دارد که بتوانم در مورد نحوه بسته بندی صحیح سرورها در رک ها بخوانم؟

متوجه شدم که چنین متنی را نمی دانم، بنابراین متن خودم را نوشتم.

اولاً، این متن در مورد سرورهای فیزیکی در مراکز داده فیزیکی (DC) است. ثانیاً، ما معتقدیم که سرورهای بسیار زیادی وجود دارد: صدها هزار؛ برای تعداد کمتر این متن معنی ندارد. سوم، ما در نظر می گیریم که سه محدودیت داریم: فضای فیزیکی در رک ها، منبع تغذیه در هر رک، و اجازه دهید رک ها در ردیف قرار بگیرند تا بتوانیم از یک سوئیچ ToR برای اتصال سرورها در رک های مجاور استفاده کنیم.

پاسخ به این سوال بسیار بستگی به این دارد که چه پارامتری را بهینه می کنیم و چه چیزی را می توانیم تغییر دهیم تا به بهترین نتیجه برسیم. به عنوان مثال، ما فقط باید حداقل فضا را اشغال کنیم تا بیشتر برای رشد بیشتر باقی بمانیم. یا شاید در انتخاب ارتفاع قفسه‌ها، قدرت هر رک، سوکت‌های PDU، تعداد رک‌های یک گروه کلید (یک سوئیچ برای 1، 2 یا 3 رک)، طول سیم‌ها و کار کشیدن آزادی داشته باشیم. این در انتهای ردیف ها بسیار مهم است: با 10 رک پشت سر هم و 3 رک در هر سوئیچ، باید سیم ها را به ردیف دیگری بکشید یا از پورت های سوئیچ کمتر استفاده کنید) و غیره و غیره. داستان های جداگانه: انتخاب سرورها و انتخاب دی سی ها، فرض می کنیم که آنها انتخاب شده اند.

خوب است که برخی از تفاوت های ظریف و جزییات، به ویژه میانگین/حداکثر مصرف سرورها و نحوه تامین برق به ما را درک کنیم. بنابراین، اگر ما یک منبع تغذیه روسی 230 ولت و یک فاز در هر رک داشته باشیم، یک دستگاه 32 آمپری می تواند 7 کیلو وات را تحمل کند. فرض کنید ما به صورت اسمی برای هر رک 6 کیلو وات پرداخت می کنیم. اگر ارائه دهنده مصرف ما را فقط برای یک ردیف 10 رک و نه برای هر رک اندازه گیری کند، و اگر دستگاه در قطع 7 کیلووات مشروط تنظیم شده باشد، از نظر فنی می توانیم در یک رک 6.9 کیلووات، در رک دیگر 5.1 کیلو وات و همه چیز درست خواهد شد - مجازات نیست.

معمولا هدف اصلی ما به حداقل رساندن هزینه هاست. بهترین معیار برای اندازه گیری کاهش TCO (هزینه کل مالکیت) است. از قطعات زیر تشکیل شده است:

• CAPEX: خرید زیرساخت DC، سرورها، سخت افزار شبکه و کابل کشی
• OPEX: اجاره DC، مصرف برق، تعمیر و نگهداری. OPEX به عمر سرویس بستگی دارد. منطقی است که آن را 3 سال فرض کنیم.

بسته به اینکه تک تک تکه‌ها چقدر در کل کیک بزرگ هستند، باید گران‌ترین آنها را بهینه کنیم و اجازه دهیم بقیه از تمام منابع باقی‌مانده تا حد امکان بهینه استفاده کنند.

فرض کنید یک DC موجود داریم، ارتفاع رک از واحدهای H (به عنوان مثال H=47)، برق در هر رک Prack (Prack=6kW) وجود دارد، و ما تصمیم گرفتیم از سرورهای دو واحدی h=2U استفاده کنیم. ما 2..4 واحد را از قفسه سوئیچ ها، پچ پنل ها و سازمان دهنده ها حذف خواهیم کرد. آن ها از نظر فیزیکی، ما سرورهای Sh=rounddown((H-2..4)/h) را در رک خود داریم (یعنی Sh = rounddown((47-4)/2)=21 سرور در هر رک). این ش را به یاد بیاوریم.

در حالت ساده، همه سرورها در یک رک یکسان هستند. در مجموع، اگر یک رک را با سرورها پر کنیم، در هر سرور می‌توانیم به طور متوسط ​​توان Pserv=Prack/Sh را خرج کنیم (Pserv = 6000W/21 = 287W). برای سادگی، مصرف سوئیچ را در اینجا نادیده می گیریم.

بیایید یک قدم را کنار بگذاریم و تعیین کنیم که حداکثر مصرف سرور Pmax چقدر است. اگر بسیار ساده، بسیار ناکارآمد و کاملاً ایمن است، آنچه را که در منبع تغذیه سرور نوشته شده است می خوانیم - این همان است.

اگر پیچیده تر و کارآمدتر باشد، TDP (بسته طراحی حرارتی) همه اجزا را می گیریم و خلاصه می کنیم (این خیلی درست نیست، اما ممکن است).

معمولاً ما TDP مؤلفه‌ها را نمی‌دانیم (به جز CPU)، بنابراین صحیح‌ترین و همچنین پیچیده‌ترین رویکرد را در پیش می‌گیریم (به یک آزمایشگاه نیاز داریم) - یک سرور آزمایشی با پیکربندی مورد نیاز را می‌گیریم و آن را بارگذاری می‌کنیم. به عنوان مثال، با Linpack (CPU و حافظه) و fio (دیسک) مصرف را اندازه گیری می کنیم. اگر آن را جدی بگیریم، باید گرم ترین محیط را در راهروی سرد در حین آزمایش ایجاد کنیم، زیرا این امر هم بر مصرف فن و هم بر مصرف CPU تأثیر می گذارد. ما حداکثر مصرف یک سرور خاص با یک پیکربندی خاص را در این شرایط خاص تحت این بار خاص دریافت می کنیم. منظور ما صرفاً این است که سیستم عامل جدید سیستم، نسخه نرم افزاری متفاوت و سایر شرایط ممکن است بر نتیجه تأثیر بگذارد.

بنابراین، به Pserv و نحوه مقایسه آن با Pmax برگردیم. مهم این است که بدانید خدمات چگونه کار می کند و اعصاب مدیر فنی شما چقدر قوی است.

اگر اصلاً ریسک نکنیم، معتقدیم که همه سرورها می‌توانند به طور همزمان حداکثر مصرف خود را آغاز کنند. در همان لحظه، یک ورودی به DC ممکن است رخ دهد. حتی در این شرایط، infra باید سرویس ارائه دهد، بنابراین Pserv ≡ Pmax. این رویکردی است که در آن قابلیت اطمینان بسیار مهم است.

اگر مدیر فناوری نه تنها به امنیت ایده آل، بلکه به پول شرکت نیز فکر می کند و به اندازه کافی شجاع است، می توانید تصمیم بگیرید که

• ما شروع به مدیریت فروشندگان خود کرده ایم، به ویژه، ما نگهداری برنامه ریزی شده را در زمان اوج بار برنامه ریزی شده ممنوع می کنیم تا افت یک ورودی را به حداقل برسانیم.
• و/یا معماری ما به شما اجازه می‌دهد یک رک/ردیف/دی سی را از دست بدهید، اما خدمات همچنان به کار خود ادامه می‌دهند.
• و/یا بار را به خوبی به صورت افقی در سراسر قفسه ها پخش می کنیم، بنابراین خدمات ما هرگز به حداکثر مصرف در یک قفسه با هم نخواهند رسید.

در اینجا نه تنها حدس زدن، بلکه نظارت بر مصرف و دانستن اینکه سرورها در شرایط عادی و پیک چگونه واقعاً برق مصرف می کنند بسیار مفید است. بنابراین، پس از کمی تجزیه و تحلیل، مدیر فناوری هر آنچه را که دارد فشرده می کند و می گوید: "ما به طور داوطلبانه تصمیم می گیریم که حداکثر میانگین قابل دستیابی حداکثر مصرف سرور در هر رک ** خیلی** کمتر از حداکثر مصرف باشد." مشروط Pserv = 0.8* Pmax.

و سپس یک رک 6 کیلو وات دیگر نمی تواند 16 سرور با Pmax = 375W را در خود جای دهد، اما 20 سرور با Pserv = 375W * 0.8 = 300W می تواند در خود جای دهد. آن ها 25 درصد سرور بیشتر این یک صرفه جویی بسیار بزرگ است - از این گذشته، ما بلافاصله به رک های 25٪ کمتر نیاز داریم (و همچنین در PDU ها، سوئیچ ها و کابل ها صرفه جویی خواهیم کرد). یک عیب جدی چنین راه حلی این است که باید دائماً نظارت کنیم که مفروضات ما هنوز درست هستند. اینکه نسخه سفت‌افزار جدید به‌طور قابل‌توجهی عملکرد فن‌ها و مصرف را تغییر نمی‌دهد، این که توسعه ناگهان با نسخه جدید شروع به استفاده از سرورها با کارآمدتر نکرد (بخوانید: آنها به بارگذاری بیشتر و مصرف بیشتر روی سرور دست یافتند). به هر حال، پس فرضیات اولیه و نتیجه گیری های ما بلافاصله نادرست می شوند. این خطری است که باید مسئولانه گرفته شود (یا از آن اجتناب شود و سپس برای قفسه هایی که به وضوح استفاده نشده اند پرداخت شود).

یک نکته مهم - در صورت امکان باید سعی کنید سرورها را از سرویس های مختلف به صورت افقی در رک ها توزیع کنید. این امر ضروری است تا زمانی که یک دسته از سرورها برای یک سرویس می‌رسند، موقعیت‌هایی اتفاق نمی‌افتد، رک‌ها به صورت عمودی با آن بسته می‌شوند تا «تراکم» افزایش یابد (زیرا اینطور آسان‌تر است). در واقعیت، معلوم می شود که یک رک با سرورهای کم بار یکسان همان سرویس پر شده است، و دیگری با سرورهای به همان اندازه پر بار پر شده است. احتمال سقوط دوم به طور قابل توجهی بیشتر است، زیرا مشخصات بار یکسان است و همه سرورها با هم در این رک در نتیجه افزایش بار شروع به مصرف یکسان می کنند.

بیایید به توزیع سرورها در رک ها برگردیم. ما فضای رک فیزیکی و محدودیت‌های قدرت را بررسی کرده‌ایم، حالا بیایید به شبکه نگاه کنیم. می توانید از سوئیچ هایی با پورت های 24/32/48 N استفاده کنید (به عنوان مثال، ما سوئیچ های ToR 48 پورت داریم). خوشبختانه، اگر به کابل های شکسته فکر نکنید، گزینه های زیادی وجود ندارد. ما در حال بررسی سناریوهایی هستیم که در گروه Rnet یک سوئیچ در هر رک، یک سوئیچ برای دو یا سه رک داشته باشیم. به نظر من بیش از سه قفسه در یک گروه خیلی زیاد است، زیرا ... مشکل کابل کشی بین قفسه ها بسیار بزرگتر می شود.

بنابراین، برای هر سناریوی شبکه (1، 2 یا 3 رک در یک گروه)، سرورها را بین رک ها توزیع می کنیم:

Srack = دقیقه (Sh، گرد کردن (Prack/Pserv)، گرد کردن (N/Rnet))

بنابراین، برای گزینه ای با 2 قفسه در یک گروه:

Srack2 = min(21، rounddown(6000/300)، rounddown(48/2)) = min(21، 20، 24) = 20 سرور در هر رک.

ما گزینه های باقی مانده را به همین ترتیب در نظر می گیریم:

Srack1 = 20
Srack3 = 16

و ما تقریباً آنجا هستیم. ما تعداد رک‌ها را می‌شماریم تا همه سرورهایمان را S توزیع کنیم (بگذارید 1000 باشد):

R = گردآوری (S / (Srack * Rnet)) * Rnet

R1 = گردآوری (1000 / (20 * 1)) * 1 = 50 * 1 = 50 قفسه

R2 = گردآوری (1000 / (20 * 2)) * 2 = 25 * 2 = 50 قفسه

R3 = گردآوری (1000 / (16 * 3)) * 3 = 25 * 2 = 63 قفسه

در مرحله بعد، TCO را برای هر گزینه بر اساس تعداد رک ها، تعداد سوئیچ های مورد نیاز، کابل کشی و غیره محاسبه می کنیم. ما گزینه ای را انتخاب می کنیم که TCO کمتر باشد. سود!

توجه داشته باشید که اگرچه تعداد قفسه های مورد نیاز برای گزینه های 1 و 2 یکسان است، اما قیمت آنها متفاوت خواهد بود، زیرا تعداد سوئیچ ها برای گزینه دوم نصف است و طول کابل های مورد نیاز بیشتر است.

P.S. اگر بتوانید با قدرت هر رک و ارتفاع رک بازی کنید، تغییرپذیری افزایش می یابد. اما این فرآیند را می توان به آنچه در بالا توضیح داده شد، با مرور گزینه ها کاهش داد. بله، ترکیبات بیشتری وجود خواهد داشت، اما هنوز تعداد بسیار محدودی وجود دارد - منبع تغذیه قفسه برای محاسبه را می توان در مراحل 1 کیلو وات افزایش داد، رک های معمولی در تعداد محدودی از اندازه های استاندارد عرضه می شوند: 42U، 45U، 47U، 48U ، 52U. و در اینجا تجزیه و تحلیل What-If اکسل در حالت جدول داده می تواند به محاسبات کمک کند. ما به صفحات دریافتی نگاه می کنیم و حداقل را انتخاب می کنیم.

منبع: www.habr.com