مشکل
معماری Hyper-Converged همخوانی خوبی با برخی از سناریوها نداشته اما حالتهای معلومی وجود دارد که در آنها لایههای جداگانه محاسبه و ذخیرهسازی بهتر از کلاستر Hyper-Converged کار میکنند. به این معنی که بروزرسانی پارامترهای سخت افزار محاسبه و ذخیرهسازی هر دو همزمان خواهد بود. اجازه دهید کمی بحث را باز کنیم:
گسترش محیط مجازی را در دو بعد فرض میکنیم:
– منابع محاسباتی (CPU,RAM,etc )
– منابع ذخیره سازی (IOPS, Capacity)
در سیستمهای Hyper-Converged هر Host در حال اجرای لایههای محاسباتی و ذخیره سازی بر روی یک سخت افزار در یک زمان میباشد. در نتیجه، افزایش یک بعد از ابعاد فرض گرفته شده در بالا افزایش دیگر ابعاد را به خوبی موجب میشود، اما مشکل اینجاست که افزایش بعد دوم ممکن است نیاز نباشد. در نتیجه منابع مالی صرف شده برای منابع سخت افزاری که استفاده نمیشوند از بین رفته است.
راهکار
StarWind Virtual SAN از هردو معماری، Hyper-Converged و جداسازی محاسبه و ذخیرهسازی پشتیبانی میکند. مادامی که اجرای لایه محاسبه و ذخیره جدا از یکدیگر هستند، این ممکن است مقیاس منایع محاسبات و ذخیره سازی صرف نظر از قدرت هرکدام نسبت به دیگری، مستقل باشند. در نتیجه سیستم بهتر میتواند دستورات را تنظیم کند در حالیکه CapEx و OpEx در حال مصرف هستند، از آنجا که نیازی نیست سختافزاری خریداری شود که بی استفاده بماند؛ بنابراین این سیستم میتواند برای یک کار مشخص ایجاد شده باشد.
وقتی StarWind در حال سرویسدهی در سناریوی جداسازی محاسبه و ذخیرهسازی میباشد، جایی که کلاسترها در حال سرویسدهی خارج از توان محاسباتی هستند، نیاز است به Hypervisor مورد نظر CPU و RAM بیشتری اضافه شود. درحالیکه ظرفیت Storage و عملکرد آن همچنان همان طور باقی خواهدماند. به همین ترتیب، اگر سیستم خارج از Storgae IOPS و ظرفیتش سرویس دهد، این بعد میتواند براحتی و بدون تاثیر بر روی توان محاسباتی بوسیله اضافه کردن Storage Node بروز شود.
نتیجه گیری
سرویس دهی StarWind به عنوان لایه جداگانه ذخیرهسازی از لایه محاسبات، کاهش قابل توجهی در CapEx و OpEx بوسیله اجازه دادن به منابع سختافزاری که در سیستم ذخیرهسازی نصب شدهاند را موجب میشود. همچنین این سناریو سیستم ذخیرهسازی را جهت انجام دستورات بوسیله مدیریت دسترسی به منابع محاسباتی و ذخیره سازی همراه با استفاده از اهرمهای مختلف بهبود میبخشد.