ادمین بدون دست = ابر همگرایی؟

این افسانه ای است که در زمینه سخت افزار سرور کاملاً رایج است. در عمل، راه حل های بیش همگرا (زمانی که همه چیز در یک واحد است) برای بسیاری از چیزها مورد نیاز است. از لحاظ تاریخی، اولین معماری ها توسط آمازون و گوگل برای خدمات خود توسعه داده شد. سپس ایده ساخت یک مزرعه محاسباتی از گره های یکسان بود که هر کدام دیسک های خاص خود را داشتند. همه اینها توسط برخی از نرم افزارهای تشکیل دهنده سیستم (hypervisor) متحد شد و به ماشین های مجازی تقسیم شد. هدف اصلی حداقل تلاش برای سرویس دهی یک گره و حداقل مشکلات در هنگام مقیاس بندی است: فقط هزار یا دو سرور دیگر را خریداری کنید و آنها را در نزدیکی وصل کنید. در عمل، این موارد مجزا هستند، و اغلب ما در مورد تعداد کمتری از گره ها و معماری کمی متفاوت صحبت می کنیم.

اما مزیت یکسان باقی می ماند - سهولت باورنکردنی در مقیاس بندی و مدیریت. نکته منفی این است که وظایف مختلف منابع را به طور متفاوتی مصرف می کنند و در برخی جاها دیسک های محلی زیادی وجود خواهد داشت، در برخی دیگر حافظه رم کم خواهد بود و به همین ترتیب، یعنی برای انواع مختلف کارها، استفاده از منابع کاهش می یابد.

به نظر می رسد که برای سهولت در راه اندازی 10 تا 15 درصد بیشتر پرداخت می کنید. این همان چیزی است که جرقه افسانه در عنوان را زد. ما زمان زیادی را صرف یافتن این موضوع کردیم که این فناوری در کجا به طور بهینه اعمال شود و آن را پیدا کردیم. واقعیت این است که سیسکو سیستم های ذخیره سازی خود را نداشت، اما آنها یک بازار سرور کامل می خواستند. و Cisco Hyperflex را ساختند - راه حلی با ذخیره سازی محلی روی گره ها.

و این به طور ناگهانی یک راه حل بسیار خوب برای مراکز داده پشتیبان (Disaster Recovery) بود. حالا به شما می گویم چرا و چگونه. و من تست های خوشه ای را به شما نشان خواهم داد.

جایی که نیاز است

بیش همگرایی عبارت است از:

1. انتقال دیسک به گره های محاسباتی
2. ادغام کامل زیرسیستم ذخیره سازی با زیرسیستم مجازی سازی.
3. انتقال/ادغام با زیرسیستم شبکه

این ترکیب به شما اجازه می دهد تا بسیاری از ویژگی های سیستم ذخیره سازی را در سطح مجازی سازی و همه را از یک پنجره کنترل پیاده سازی کنید.

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

در مورد مراکز داده پشتیبان، ما معمولاً در مورد یک تسهیلات راه دور در سایتی در آن طرف شهر یا کلاً در شهر دیگری صحبت می کنیم. این به شما امکان می دهد در صورت خرابی جزئی یا کامل مرکز داده اصلی، سیستم های حیاتی را بازیابی کنید. داده های فروش به طور مداوم در آنجا تکثیر می شوند و این تکرار می تواند در سطح برنامه یا در سطح دستگاه بلوک (ذخیره سازی) باشد.

بنابراین، اکنون در مورد طراحی و آزمایشات سیستم، و سپس در مورد چند سناریو کاربردی واقعی با داده های صرفه جویی صحبت خواهم کرد.

تستها

نمونه ما از چهار سرور تشکیل شده است که هر کدام دارای 10 درایو SSD با ظرفیت 960 گیگابایت است. یک دیسک اختصاصی برای ذخیره عملیات نوشتن و ذخیره ماشین مجازی سرویس وجود دارد. راه حل خود نسخه چهارم است. اولی صراحتاً خام است (با قضاوت بر اساس بررسی ها)، دومی مرطوب است، سومی در حال حاضر کاملاً پایدار است، و این یکی را می توان انتشار پس از پایان آزمایش بتا برای عموم مردم نامید. در طول آزمایش من هیچ مشکلی ندیدم، همه چیز مانند یک ساعت کار می کند.

تغییرات در v4دسته ای از اشکالات رفع شده است.

در ابتدا، این پلتفرم فقط می توانست با هایپروایزر VMware ESXi کار کند و تعداد کمی از گره ها را پشتیبانی می کرد. همچنین، روند استقرار همیشه با موفقیت به پایان نمی رسید، برخی از مراحل باید دوباره راه اندازی می شد، مشکلاتی در به روز رسانی از نسخه های قدیمی وجود داشت، داده ها در رابط کاربری گرافیکی همیشه به درستی نمایش داده نمی شدند (اگرچه من هنوز از نمایش نمودارهای عملکرد راضی نیستم. ، گاهی اوقات مشکلاتی در رابط مجازی سازی ایجاد می شود.

اکنون تمام مشکلات دوران کودکی برطرف شده است، HyperFlex می تواند هر دو ESXi و Hyper-V را مدیریت کند، به علاوه ممکن است:

1. ایجاد یک خوشه کشیده
2. ایجاد یک کلاستر برای دفاتر بدون استفاده از Fabric Interconnect، از دو تا چهار گره (ما فقط سرورها را می خریم).
3. امکان کار با سیستم های ذخیره سازی خارجی.
4. پشتیبانی از کانتینرها و Kubernetes.
5. ایجاد مناطق در دسترس
6. اگر عملکرد داخلی راضی کننده نباشد، با VMware SRM ادغام می شود.

معماری تفاوت چندانی با راه حل های رقبای اصلی خود ندارد؛ آنها دوچرخه ایجاد نکرده اند. همه اینها بر روی پلتفرم مجازی سازی VMware یا Hyper-V اجرا می شود. سخت افزار بر روی سرورهای UCS اختصاصی Cisco میزبانی می شود. کسانی هستند که از پیچیدگی نسبی راه اندازی اولیه، تعداد زیادی دکمه، سیستم غیر پیش پا افتاده قالب ها و وابستگی ها از پلتفرم متنفرند، اما کسانی هم هستند که ذن را یاد گرفته اند، از این ایده الهام گرفته اند و دیگر نمی خواهند. برای کار با سرورهای دیگر

ما راه حلی را برای VMware در نظر خواهیم گرفت، زیرا این راه حل در ابتدا برای آن ایجاد شده بود و عملکرد بیشتری دارد؛ Hyper-V در طول مسیر اضافه شد تا با رقبا همگام شود و انتظارات بازار را برآورده کند.

مجموعه ای از سرورهای پر از دیسک وجود دارد. دیسک هایی برای ذخیره سازی داده ها (SSD یا HDD - با توجه به سلیقه و نیاز شما) وجود دارد، یک دیسک SSD برای ذخیره سازی وجود دارد. هنگام نوشتن داده ها در دیتا استور، داده ها در لایه کش (دیسک SSD اختصاصی و رم VM سرویس) ذخیره می شوند. به طور موازی، بلوکی از داده ها به گره های خوشه ارسال می شود (تعداد گره ها به ضریب تکرار خوشه بستگی دارد). پس از تایید از تمام گره ها در مورد ضبط موفق، تایید ضبط به Hypervisor و سپس VM ارسال می شود. داده های ضبط شده کپی شده، فشرده شده و روی دیسک های ذخیره سازی در پس زمینه نوشته می شوند. در عین حال، همیشه یک بلوک بزرگ روی دیسک های ذخیره سازی و به صورت متوالی نوشته می شود که باعث کاهش بار روی دیسک های ذخیره سازی می شود.

Deduplication و فشرده سازی همیشه فعال هستند و نمی توان آنها را غیرفعال کرد. داده ها مستقیماً از دیسک های ذخیره سازی یا از حافظه نهان RAM خوانده می شوند. اگر از یک پیکربندی ترکیبی استفاده شود، قرائت‌ها نیز روی SSD ذخیره می‌شوند.

داده ها به مکان فعلی ماشین مجازی متصل نیستند و به طور مساوی بین گره ها توزیع می شوند. این رویکرد به شما امکان می دهد تمام دیسک ها و رابط های شبکه را به طور یکسان بارگذاری کنید. یک نقطه ضعف آشکار وجود دارد: ما نمی توانیم تأخیر خواندن را تا حد ممکن کاهش دهیم، زیرا هیچ تضمینی برای در دسترس بودن داده ها به صورت محلی وجود ندارد. اما من معتقدم که این یک فداکاری جزئی در مقایسه با مزایای دریافت شده است. علاوه بر این، تاخیرهای شبکه به مقادیری رسیده است که عملاً بر نتیجه کلی تأثیر نمی گذارد.

یک سرویس ویژه VM Cisco HyperFlex Data Platform Controller که روی هر گره ذخیره سازی ایجاد می شود، مسئولیت کل منطق عملیات زیرسیستم دیسک را بر عهده دارد. در پیکربندی VM سرویس ما، هشت vCPU و 72 گیگابایت رم اختصاص داده شد که چندان هم کم نیست. یادآوری می کنم که خود هاست دارای 28 هسته فیزیکی و 512 گیگابایت رم است.

سرویس VM مستقیماً با ارسال کنترلر SAS به VM به دیسک های فیزیکی دسترسی دارد. ارتباط با Hypervisor از طریق یک ماژول ویژه IOVisor، که عملیات I/O را متوقف می کند و با استفاده از عاملی که به شما امکان می دهد دستورات را به Hypervisor API ارسال کنید، انجام می شود. عامل مسئول کار با عکس های فوری و کلون های HyperFlex است.

منابع دیسک به صورت اشتراک های NFS یا SMB در هایپروایزر نصب می شوند (بسته به نوع هایپروایزر، حدس بزنید کدام یک کجاست). و در زیر هود، این یک سیستم فایل توزیع شده است که به شما امکان می دهد ویژگی های سیستم های ذخیره سازی کامل بزرگسالان را اضافه کنید: تخصیص حجم نازک، فشرده سازی و حذف مجدد، عکس های فوری با استفاده از فناوری Redirect-on-Write، تکرار همزمان/ناهمزمان.

سرویس VM دسترسی به رابط مدیریت وب زیرسیستم HyperFlex را فراهم می کند. با vCenter یکپارچه سازی وجود دارد و اکثر کارهای روزمره را می توان از طریق آن انجام داد، اما برای مثال، اگر قبلاً به یک رابط سریع HTML5 تغییر داده اید یا از یک کلاینت کامل Flash استفاده می کنید، ذخیره داده ها برای برش از یک وب کم جداگانه راحت تر است. با یکپارچگی کامل در وب کم سرویس می توانید عملکرد و وضعیت دقیق سیستم را مشاهده کنید.

نوع دیگری از گره در یک خوشه وجود دارد - گره های محاسباتی. اینها می توانند سرورهای رک یا تیغه ای بدون دیسک داخلی باشند. این سرورها می توانند ماشین های مجازی را اجرا کنند که داده های آنها در سرورهای دارای دیسک ذخیره می شود. از نقطه نظر دسترسی به داده ها، تفاوتی بین انواع گره ها وجود ندارد، زیرا معماری شامل انتزاع از مکان فیزیکی داده ها است. حداکثر نسبت گره های محاسباتی به گره های ذخیره سازی 2:1 است.

استفاده از گره‌های محاسباتی انعطاف‌پذیری را هنگام مقیاس‌بندی منابع خوشه‌ای افزایش می‌دهد: اگر فقط به CPU/RAM نیاز داریم، نیازی به خرید گره‌های اضافی با دیسک نداریم. علاوه بر این، می توانیم یک blade cage اضافه کنیم و در قرار دادن رک سرورها صرفه جویی کنیم.

در نتیجه، ما یک پلت فرم ابرهمگرا با ویژگی های زیر داریم:

• حداکثر 64 گره در یک خوشه (تا 32 گره ذخیره سازی).
• حداقل تعداد گره ها در یک خوشه سه (دو برای یک خوشه Edge) است.
• مکانیسم افزونگی داده ها: آینه سازی با ضریب تکرار 2 و 3.
• خوشه مترو
• همانندسازی ناهمزمان VM به یک خوشه HyperFlex دیگر.
• هماهنگ سازی تغییر ماشین های مجازی به یک مرکز داده از راه دور.
• عکس های فوری با استفاده از فناوری Redirect-on-Write.
• تا 1 PB فضای قابل استفاده در ضریب تکرار 3 و بدون کپی برداری. ما ضریب تکرار 2 را در نظر نمی گیریم، زیرا این گزینه برای فروش جدی نیست.

مزیت بزرگ دیگر سهولت مدیریت و استقرار است. تمام پیچیدگی های راه اندازی سرورهای UCS توسط یک VM تخصصی که توسط مهندسان سیسکو تهیه شده است، انجام می شود.

پیکربندی میز تست:

• 2 x Cisco UCS Fabric Interconnect 6248UP به عنوان یک خوشه مدیریت و اجزای شبکه (48 پورت در حالت اترنت 10G/FC 16G کار می کنند).
• چهار سرور Cisco UCS HXAF240 M4.

مشخصات سرور:

پردازنده

2 x Intel® Xeon® E5-2690 v4

رم

16 x 32 گیگابایت DDR4-2400-MHz RDIMM/PC4-19200/Dual Rank/x4/1.2v

شبکه ارتباطی

UCSC-MLOM-CSC-02 (VIC 1227). 2 پورت اترنت 10G

ذخیره سازی HBA

Cisco 12G Modular SAS Pass through Controller

دیسک های ذخیره سازی

1 عدد SSD اینتل S3520 120 گیگابایت، 1 عدد SSD سامسونگ MZ-IES800D، 10 عدد SSD سامسونگ PM863a 960 گیگابایت

گزینه های پیکربندی بیشترعلاوه بر سخت افزار انتخاب شده، گزینه های زیر در حال حاضر در دسترس هستند:

• HXAF240c M5.
• یک یا دو CPU از Intel Silver 4110 تا Intel Platinum I8260Y. نسل دوم موجود است
• 24 اسلات حافظه، نوار از 16 گیگابایت RDIMM 2600 تا 128 گیگابایت LRDIMM 2933.
• از 6 تا 23 دیسک داده، یک دیسک کش، یک دیسک سیستم و یک دیسک بوت.

درایوهای ظرفیت

• HX-SD960G61X-EV 960 گیگابایت 2.5 اینچ ارزش سازمانی 6G SATA SSD (1X endurance) SAS 960 گیگابایت.
• HX-SD38T61X-EV 3.8TB 2.5 اینچی ارزش سازمانی 6G SATA SSD (1X endurance) SAS 3.8 TB.
• حافظه پنهان درایوها
• HX-NVMEXPB-I375 375 گیگابایت 2.5 اینچ Optane Drive، Extreme Perf & Endurance.
• HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. پرف. NVMe SSD (استقامت 3X) NVMe 1.6 ترابایت.
• HX-SD400G12TX-EP 400GB 2.5 اینچ Ent. پرف. 12G SAS SSD (10X استقامت) SAS 400 گیگابایت.
• HX-SD800GBENK9** 800 گیگابایت 2.5 اینچ ورودی. پرف. 12G SAS SED SSD (استقامت 10X) SAS 800 گیگابایت.
• HX-SD16T123X-EP 1.6TB 2.5 اینچی عملکرد سازمانی 12G SAS SSD (استقامت 3X).

درایوهای سیستم/log

• HX-SD240GM1X-EV 240GB 2.5 اینچی ارزش سازمانی 6G SATA SSD (نیاز به ارتقاء دارد).

درایوهای بوت

• HX-M2-240 گیگابایت 240 گیگابایت SATA M.2 SSD SATA 240 گیگابایت.

از طریق پورت های اترنت 40G، 25G یا 10G به شبکه متصل شوید.

FI می تواند HX-FI-6332 (40G)، HX-FI-6332-16UP (40G)، HX-FI-6454 (40G/100G) باشد.

خود آزمون

برای تست زیرسیستم دیسک از HCIBench 2.2.1 استفاده کردم. این یک ابزار رایگان است که به شما امکان می دهد ایجاد بار از چندین ماشین مجازی را به طور خودکار انجام دهید. خود بار توسط fio معمولی تولید می شود.

خوشه ما از چهار گره تشکیل شده است، ضریب تکرار 3، همه دیسک ها فلش هستند.

برای آزمایش، چهار دیتا استور و هشت ماشین مجازی ایجاد کردم. برای تست نوشتن، فرض بر این است که دیسک کش پر نیست.

نتایج آزمون به شرح زیر است:

100% خواندن 100% تصادفی

0% خواندن 100% تصادفی

عمق بلوک / صف

128

256

512

1024

2048

128

256

512

1024

2048

4K

0,59 ms 213804 IOPS

0,84 ms 303540 IOPS

1,36ms 374348 IOPS

2.47 ms 414116 IOPS

4,86ms 420180 IOPS

2,22 ms 57408 IOPS

3,09 ms 82744 IOPS

IPOS 5,02 ms 101824

8,75 ms 116912 IOPS

17,2 ms 118592 IOPS

8K

0,67 ms 188416 IOPS

0,93 ms 273280 IOPS

1,7 ms 299932 IOPS

2,72 ms 376,484 IOPS

5,47 ms 373,176 IOPS

3,1 ms 41148 IOPS

4,7 ms 54396 IOPS

7,09 ms 72192 IOPS

12,77 ms 80132 IOPS

16K

0,77 ms 164116 IOPS

1,12 ms 228328 IOPS

1,9 ms 268140 IOPS

3,96 ms 258480 IOPS

3,8 ms 33640 IOPS

6,97 ms 36696 IOPS

11,35 ms 45060 IOPS

32K

1,07 ms 119292 IOPS

1,79 ms 142888 IOPS

3,56 ms 143760 IOPS

7,17 ms 17810 IOPS

11,96 ms 21396 IOPS

64K

1,84 ms 69440 IOPS

3,6 ms 71008 IOPS

7,26 ms 70404 IOPS

11,37 ms 11248 IOPS

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

• خواندن ترتیبی 4432 مگابایت بر ثانیه.
• نوشتن متوالی 804 مگابایت بر ثانیه.
• اگر یکی از کنترلرها خراب شود (شکست یک ماشین مجازی یا میزبان)، افت عملکرد دو برابر می شود.
• اگر دیسک ذخیره سازی خراب شود، کاهش 1/3 است. بازسازی دیسک 5 درصد از منابع هر کنترلر را می گیرد.

در یک بلوک کوچک، ما توسط عملکرد کنترلر (ماشین مجازی) محدود می شویم، CPU آن 100٪ بارگذاری می شود و زمانی که بلوک افزایش می یابد، توسط پهنای باند پورت محدود می شویم. 10 گیگابیت در ثانیه برای باز کردن پتانسیل سیستم AllFlash کافی نیست. متأسفانه، پارامترهای پایه نمایشی ارائه شده به ما اجازه نمی دهد تا عملکرد را با سرعت 40 گیگابیت بر ثانیه آزمایش کنیم.

به نظر من از آزمایش‌ها و مطالعه معماری، به دلیل الگوریتمی که داده‌ها را بین همه میزبان‌ها قرار می‌دهد، عملکرد قابل پیش‌بینی و مقیاس‌پذیری دریافت می‌کنیم، اما این نیز در هنگام خواندن یک محدودیت است، زیرا می‌توان بیشتر از دیسک‌های محلی فشرده کرد. در اینجا ممکن است شبکه مولدتری ذخیره شود، به عنوان مثال، FI با سرعت 40 گیگابیت بر ثانیه در دسترس است.

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

استفاده واقعی

برای سازماندهی یک مرکز داده پشتیبان، می توانید از دو روش استفاده کنید (ما قرار دادن یک نسخه پشتیبان در یک سایت راه دور را در نظر نمی گیریم):

1. فعال - منفعل. همه برنامه ها در مرکز داده اصلی میزبانی می شوند. همانندسازی همزمان یا ناهمزمان است. اگر مرکز داده اصلی از کار بیفتد، باید نسخه پشتیبان را فعال کنیم. این را می توان به صورت دستی/اسکریپت/برنامه های ارکستراسیون انجام داد. در اینجا ما یک RPO متناسب با فرکانس تکرار دریافت خواهیم کرد و RTO به واکنش و مهارت مدیر و کیفیت توسعه/اشکال‌زدایی طرح سوئیچینگ بستگی دارد.
2. فعال-فعال. در این مورد، فقط تکرار همزمان وجود دارد؛ در دسترس بودن مراکز داده توسط یک حد نصاب/ داور که دقیقاً در سایت سوم قرار دارد تعیین می شود. RPO = 0، و RTO می تواند به 0 برسد (اگر برنامه اجازه دهد) یا برابر با زمان شکست یک گره در یک خوشه مجازی سازی باشد. در سطح مجازی سازی، یک خوشه کشیده (Metro) ایجاد می شود که به ذخیره سازی Active-Active نیاز دارد.

معمولاً می بینیم که مشتریان قبلاً یک معماری با یک سیستم ذخیره سازی کلاسیک را در مرکز داده اصلی پیاده سازی کرده اند، بنابراین ما یک معماری دیگر را برای تکرار طراحی می کنیم. همانطور که اشاره کردم، سیسکو HyperFlex تکرار ناهمزمان و ایجاد خوشه مجازی سازی طولانی را ارائه می دهد. در عین حال، ما نیازی به یک سیستم ذخیره سازی اختصاصی در سطح متوسط ​​و بالاتر با توابع تکراری گران قیمت و دسترسی Active-Active به داده ها در دو سیستم ذخیره سازی نداریم.

سناریو 1: ما یک مرکز داده اولیه و پشتیبان، یک پلت فرم مجازی سازی در VMware vSphere داریم. تمام سیستم‌های تولیدی در مرکز داده اصلی قرار دارند و همانندسازی ماشین‌های مجازی در سطح Hypervisor انجام می‌شود، این امر از روشن نگه داشتن VM در مرکز داده پشتیبان جلوگیری می‌کند. ما پایگاه داده ها و برنامه های کاربردی خاص را با استفاده از ابزارهای داخلی تکرار می کنیم و ماشین های مجازی را روشن نگه می داریم. اگر مرکز داده اصلی از کار بیفتد، سیستم ها را در مرکز داده پشتیبان راه اندازی می کنیم. ما معتقدیم که حدود 100 ماشین مجازی داریم. در حالی که مرکز داده اولیه عملیاتی است، مرکز داده آماده به کار می تواند محیط های آزمایشی و سایر سیستم ها را اجرا کند که در صورت تغییر مرکز داده اولیه، می توانند خاموش شوند. همچنین ممکن است از Replication دو طرفه استفاده کنیم. از نظر سخت افزاری چیزی تغییر نخواهد کرد.

در مورد معماری کلاسیک، ما در هر مرکز داده یک سیستم ذخیره سازی هیبریدی با دسترسی از طریق FibreChannel، ردیف کردن، حذف مجدد و فشرده سازی (اما نه آنلاین)، 8 سرور برای هر سایت، 2 سوئیچ FibreChannel و 10G اترنت نصب خواهیم کرد. برای مدیریت تکرار و سوئیچینگ در معماری کلاسیک، می‌توان از ابزارهای VMware (Replication + SRM) یا ابزارهای شخص ثالث استفاده کرد که کمی ارزان‌تر و گاهی راحت‌تر خواهند بود.

شکل نمودار را نشان می دهد.

هنگام استفاده از Cisco HyperFlex، معماری زیر به دست می آید:

برای HyperFlex، من از سرورهایی با منابع CPU/RAM بزرگ استفاده کردم، زیرا ... برخی از منابع به کنترلر HyperFlex VM خواهد رفت؛ از نظر CPU و حافظه، من حتی پیکربندی HyperFlex را کمی مجدداً تنظیم کردم تا با سیسکو بازی نکنم و منابع را برای ماشین های مجازی باقی مانده تضمین کنم. اما ما می‌توانیم سوئیچ‌های FibreChannel را رها کنیم و برای هر سرور به پورت‌های اترنت نیازی نخواهیم داشت؛ ترافیک محلی درون FI سوئیچ می‌شود.

نتیجه پیکربندی زیر برای هر مرکز داده بود:

سرورها

سرور 8 x 1U (رم 384 گیگابایت، 2 x Intel Gold 6132، FC HBA)

8 x HX240C-M5L (رم 512 گیگابایت، 2 x Intel Gold 6150، 3,2 گیگابایت SSD، 10 x 6 ترابایت NL-SAS)

SHD

سیستم ذخیره سازی هیبریدی با FC Front-End (20 ترابایت SSD، 130 ترابایت NL-SAS)

-

شبکه

2 عدد سوئیچ اترنت 10G 12 پورت

-

SAN

2 عدد سوئیچ FC 32/16 گیگابیت 24 پورت

2 عدد سیسکو UCS FI 6332

مجوزها

VMware Ent Plus

تکرار و/یا هماهنگی سوئیچینگ VM

VMware Ent Plus

من مجوزهای نرم افزار تکثیر را برای Hyperflex ارائه نکردم، زیرا این مجوز خارج از جعبه برای ما در دسترس است.

برای معماری کلاسیک، فروشنده ای را انتخاب کردم که خود را به عنوان یک تولید کننده با کیفیت بالا و ارزان معرفی کرده است. برای هر دو گزینه، من تخفیف استاندارد را برای یک راه حل خاص اعمال کردم و در نتیجه قیمت های واقعی دریافت کردم.

راه حل Cisco HyperFlex 13٪ ارزان تر بود.

سناریو 2: ایجاد دو مرکز داده فعال در این سناریو، ما در حال طراحی یک کلاستر کشیده روی VMware هستیم.

معماری کلاسیک متشکل از سرورهای مجازی سازی، یک SAN (پروتکل FC) و دو سیستم ذخیره سازی است که می توانند به حجمی که بین آنها کشیده شده است بخوانند و بنویسند. روی هر سیستم ذخیره سازی ظرفیت مفیدی برای ذخیره سازی قرار می دهیم.

در HyperFlex ما به سادگی یک Stretch Cluster با تعداد یکسان گره در هر دو سایت ایجاد می کنیم. در این حالت از ضریب تکرار 2+2 استفاده می شود.

نتیجه پیکربندی زیر است:

معماری کلاسیک

HyperFlex

سرورها

سرور 16 x 1U (رم 384 گیگابایت، 2 x Intel Gold 6132، FC HBA، 2 x 10G NIC)

16 x HX240C-M5L (512 گیگابایت رم، 2 x Intel Gold 6132، 1,6 ترابایت NVMe، 12 x 3,8 ترابایت SSD، VIC 1387)

SHD

2 x سیستم ذخیره سازی AllFlash (150 ترابایت SSD)

-

شبکه

4 عدد سوئیچ اترنت 10G 24 پورت

-

SAN

4 عدد سوئیچ FC 32/16 گیگابیت 24 پورت

4 عدد سیسکو UCS FI 6332

مجوزها

VMware Ent Plus

VMware Ent Plus

در تمام محاسبات، زیرساخت شبکه، هزینه های مرکز داده و غیره را در نظر نگرفتم: آنها برای معماری کلاسیک و برای راه حل HyperFlex یکسان خواهند بود.

از نظر هزینه، HyperFlex 5٪ گرانتر بود. در اینجا شایان ذکر است که از نظر منابع CPU / RAM من یک انحراف برای سیسکو داشتم، زیرا در پیکربندی کانال های کنترل کننده حافظه را به طور مساوی پر کردم. هزینه کمی بالاتر است، اما نه به ترتیب بزرگی، که به وضوح نشان می دهد که همگرایی بیش از حد لزوما یک "اسباب بازی برای ثروتمندان" نیست، اما می تواند با رویکرد استاندارد برای ساخت یک مرکز داده رقابت کند. این ممکن است برای کسانی که قبلاً سرورهای Cisco UCS و زیرساخت مربوط به آنها را دارند نیز جالب باشد.

از جمله مزیت ها، عدم وجود هزینه برای مدیریت SAN و سیستم های ذخیره سازی، فشرده سازی آنلاین و حذف مجدد، یک نقطه ورود واحد برای پشتیبانی (مجازی سازی، سرورها، آنها همچنین سیستم های ذخیره سازی هستند)، صرفه جویی در فضا (اما نه در همه سناریوها)، ساده سازی عملیات

در مورد پشتیبانی، در اینجا شما آن را از یک فروشنده - Cisco - دریافت می کنید. با توجه به تجربه من با سرورهای Cisco UCS، من آن را دوست دارم؛ مجبور نبودم آن را در HyperFlex باز کنم، همه چیز دقیقاً یکسان کار می کرد. مهندسان به سرعت پاسخ می دهند و می توانند نه تنها مشکلات معمولی، بلکه موارد لبه پیچیده را نیز حل کنند. گاهی اوقات با سؤالاتی به آنها مراجعه می کنم: "آیا می توان این کار را انجام داد، آن را پیچ کنید؟" یا «من چیزی را در اینجا پیکربندی کردم، و نمی‌خواهد کار کند. کمک!" - آنها با صبر و حوصله راهنمای لازم را در آنجا پیدا می کنند و به اقدامات صحیح اشاره می کنند؛ آنها پاسخ نمی دهند: "ما فقط مشکلات سخت افزاری را حل می کنیم."

مراجع

• مشخصات
• مرکز داده مجازی
• مرکز داده در کشوی میز
• نامه من - [ایمیل محافظت شده]

منبع: www.habr.com