یکی از بازیگران جوان در بازار راه‌حل‌های Disaster Recovery، Hystax است، یک استارت‌آپ روسی از سال 2016. از آنجایی که موضوع بازیابی فاجعه بسیار محبوب است و بازار بسیار رقابتی است، استارت آپ تصمیم گرفت بر روی مهاجرت بین زیرساخت های ابری مختلف تمرکز کند. محصولی که به شما امکان می دهد یک مهاجرت ساده و سریع به ابر را سازماندهی کنید، برای مشتریان - کاربران Onlanta نیز بسیار مفید خواهد بود. . اینگونه بود که با Hystax آشنا شدم و شروع به آزمایش قابلیت های آن کردم. من در این مقاله به شما خواهم گفت که چه چیزی از آن حاصل شد.
ویژگی اصلی Hystax قابلیت گسترده آن برای پشتیبانی از پلتفرم های مختلف مجازی سازی، سیستم عامل های مهمان و سرویس های ابری است که امکان انتقال بارهای کاری خود را از هر کجا و هر مکان ممکن می کند.
این به شما این امکان را می دهد که نه تنها راه حل های DR برای افزایش تحمل خطای سرویس ها ایجاد کنید، بلکه به سرعت و انعطاف پذیری منابع را بین سایت های مختلف و هایپراسکیلرها انتقال دهید تا صرفه جویی در هزینه را افزایش دهید و بهترین راه حل را برای یک سرویس خاص در یک لحظه معین انتخاب کنید. علاوه بر پلتفرم های ذکر شده در تصویر عنوان، این شرکت همچنین به طور فعال با ارائه دهندگان ابر روسی همکاری می کند: Yandex.Cloud، CROC Cloud Services، Mail.ru و بسیاری دیگر. همچنین شایان ذکر است که در سال 2020 این شرکت مرکز تحقیق و توسعه واقع در Skolkovo را افتتاح کرد.
انتخاب یک راه حل توسط تعداد زیادی از بازیگران در بازار نشان دهنده سیاست قیمت گذاری خوب و کاربرد بالای محصول است که تصمیم گرفتیم آن را در عمل آزمایش کنیم.
بنابراین، وظیفه آزمایشی ما شامل مهاجرت از سایت تست VMware و ماشین‌های فیزیکی من به سایت ارائه‌دهنده است که توسط VMware نیز مدیریت می‌شود. بله، راه حل های زیادی وجود دارد که می تواند چنین مهاجرتی را انجام دهد، اما ما Hystax را به عنوان یک ابزار جهانی در نظر می گیریم و آزمایش مهاجرت در تمام ترکیبات ممکن به سادگی یک کار غیر واقعی است. و ابر Oncloud.ru به طور خاص بر روی VMware ساخته شده است، بنابراین این پلت فرم به عنوان یک هدف ما را به میزان بیشتری مورد توجه قرار می دهد. در مرحله بعد، من اصل اساسی عملکرد را شرح خواهم داد که به طور کلی مستقل از پلتفرم است و VMware از هر طرف می تواند با یک پلتفرم از فروشنده دیگری جایگزین شود.
اولین قدم، استقرار Hystax Acura است که پنل کنترل سیستم است.
از قالب باز می شود. بنا به دلایلی، در مورد ما کاملاً درست نبود و به جای 8 CPU توصیه شده، 16 گیگابایت با نیمی از منابع مستقر شد. بنابراین، باید به یاد داشته باشید که آنها را تغییر دهید، در غیر این صورت زیرساخت کانتینر داخل VM، که همه چیز روی آن ساخته شده است، به سادگی شروع نمی شود و پورتال غیرقابل دسترسی خواهد بود. که در منابع مورد نیاز به تفصیل شرح داده شده اند و همچنین پورت ها برای تمام اجزای سیستم.
همچنین در تنظیم آدرس IP از طریق یک الگو مشکلاتی وجود داشت، بنابراین ما آن را از کنسول تغییر دادیم. پس از این، می توانید به رابط وب ادمین بروید و ویزارد تنظیمات اولیه را تکمیل کنید.
نقطه پایانی - IP یا FQDN مرکز مجازی ما.
ورود و رمز عبور - این واضح است.
Target ESXi hostname یکی از میزبان‌های خوشه ما است که Replication روی آن انجام می‌شود.
Target datastore یکی از دیتا استورهای خوشه ما است که Replication به آن انجام خواهد شد.
IP عمومی کنترل پنل Hystax Acura – آدرسی که کنترل پنل در آن در دسترس خواهد بود.
در مورد هاست و دیتا استور کمی توضیح لازم است. واقعیت این است که Replication Hystax در سطح میزبان و دیتا استور کار می کند. در ادامه به شما خواهم گفت که چگونه می توانید هاست و دیتا استور را برای مستاجر تغییر دهید، اما مشکل متفاوت است. Hystax از کار با منابع استخر پشتیبانی نمی کند. ماکت همیشه به ریشه خوشه می رود (در زمان نوشتن این مطالب، بچه های Hystax نسخه به روز شده ای را منتشر کردند، جایی که آنها به سرعت درخواست ویژگی من را در مورد پشتیبانی از استخرهای منابع اجرا کردند). vCloud Director نیز پشتیبانی نمی شود، یعنی. اگر مانند مورد من، مستاجر حقوق مدیریت کل کلاستر را نداشته باشد، بلکه فقط به یک منبع خاص دسترسی داشته باشد، و ما به Hystax دسترسی داشته باشیم، در این صورت او می‌تواند به طور مستقل این ماشین‌های مجازی را تکثیر و راه‌اندازی کند، اما او این کار را انجام خواهد داد. قادر به دیدن آنها در زیرساخت VMware نیست، که او به آن دسترسی دارد و بر این اساس، ماشین های مجازی را بیشتر مدیریت می کند. لازم است مدیر کلاستر VM را به منبع مورد نظر منتقل کند یا آن را به vCloud Director وارد کند.
چرا اینقدر روی این نکات تمرکز می کنم؟ زیرا، تا آنجایی که من مفهوم محصول را درک می کنم، مشتری باید بتواند به طور مستقل هرگونه مهاجرت یا DR را با استفاده از پنل Acura پیاده سازی کند. اما تا کنون، پشتیبانی از VMware اندکی از سطح پشتیبانی OpenStack، جایی که مکانیسم‌های مشابهی قبلاً پیاده‌سازی شده‌اند، کمتر است.
اما بیایید به استقرار برگردیم. اول از همه، پس از راه اندازی اولیه پنل، باید اولین مستاجر را در سیستم خود ایجاد کنیم.
همه فیلدها در اینجا واضح هستند، من فقط در مورد قسمت Cloud به شما می گویم. ما قبلاً یک ابر «پیش‌فرض» داریم که در پیکربندی اولیه ایجاد کردیم. اما اگر می‌خواهیم بتوانیم هر مستاجر را در دیتا استور خودش و در استخر منابع خودش قرار دهیم، می‌توانیم با ایجاد ابرهای جداگانه برای هر یک از مشتریان خود، این کار را پیاده‌سازی کنیم.
در فرم اضافه کردن یک ابر جدید، پارامترهای مشابهی را در تنظیمات اولیه مشخص می کنیم (حتی می توانیم از همان هاست استفاده کنیم)، ذخیره داده مورد نیاز برای یک مشتری خاص را نشان می دهیم و اکنون در پارامترهای اضافی می توانیم به صورت جداگانه منبع مورد نیاز را مشخص کنیم. pool {"resource_pool" : "YOUR_POOL_NAME"}
همانطور که ممکن است متوجه شده باشید، در فرم ایجاد مستاجر چیزی در مورد تخصیص منابع یا هر سهمیه وجود ندارد - هیچ کدام از اینها در سیستم وجود ندارد. محدود کردن مستاجر در تعداد کپی‌های همزمان، تعداد ماشین‌های تکراری یا هر پارامتر دیگری غیرممکن است. بنابراین، ما اولین مستأجر را ایجاد کردیم. اکنون یک چیز کاملاً منطقی، اما اجباری وجود دارد - نصب یک عامل Cloud. این غیر منطقی است، زیرا عامل در صفحه یک مشتری خاص دانلود می شود.
در عین حال، به مستاجر ایجاد شده وابسته نیست و همه مشتریان ما از طریق آن (یا از طریق چندین، اگر آنها را مستقر کنیم) کار خواهند کرد. یک نماینده از 10 جلسه همزمان پشتیبانی می کند. یک دستگاه به عنوان یک جلسه محاسبه می شود. مهم نیست که چند دیسک دارد. تا به امروز، هیچ مکانیزمی برای مقیاس گذاری عوامل در خود آکورا تحت VMware وجود ندارد. یک لحظه ناخوشایند دیگر وجود دارد - ما این فرصت را نداریم که به "دفع" این عامل از پنل Acura نگاه کنیم تا نتیجه بگیریم که آیا نیاز به استقرار بیشتر داریم یا اینکه نصب فعلی کافی است. در نتیجه، استند به شکل زیر است:
گام بعدی برای دسترسی به پورتال مشتری ما ایجاد یک حساب کاربری است (و ابتدا نقشی که برای این کاربر اعمال می شود).
اکنون مشتری ما می تواند به طور مستقل از پورتال استفاده کند. تنها کاری که او باید انجام دهد این است که عوامل را از پورتال دانلود کرده و در کنار خود نصب کند. سه نوع عامل وجود دارد: لینوکس، ویندوز و VMware.
دو مورد اول بر روی فیزیک یا ماشین های مجازی روی هر هایپروایزر دیگری غیر از VMware نصب می شوند. نیازی به پیکربندی هیچ چیز اضافی نیست، عامل دانلود شده است و از قبل می داند کجا باید ضربه بزند و به معنای واقعی کلمه در یک دقیقه ماشین در پنل Acura قابل مشاهده خواهد بود. با عامل VMware وضعیت کمی پیچیده تر است. مشکل اینجاست که عامل VMware نیز از پورتالی که از قبل آماده شده و حاوی تنظیمات لازم است دانلود می شود. اما علاوه بر دانستن در مورد پورتال Acura ما، یک عامل VMware همچنین باید در مورد سیستم مجازی سازی که در آن مستقر می شود نیز بداند.
در واقع، هنگامی که عامل VMware را برای اولین بار دانلود می کنیم، سیستم از ما می خواهد که این داده ها را ارائه دهیم. مشکل این است که در عصر ما که عشق جهانی به امنیت است، همه نمی خواهند رمز عبور مدیریت خود را در پورتال شخص دیگری نشان دهند، که کاملاً قابل درک است. از داخل، پس از استقرار، عامل به هیچ وجه قابل پیکربندی نیست (شما فقط می توانید تنظیمات شبکه آن را تغییر دهید). در اینجا من مشکلاتی را با مشتریان محتاط پیش بینی می کنم.
بنابراین، پس از نصب عوامل، می توانیم به پنل آکورا برگردیم و تمام خودروهای خود را ببینیم.
از آنجایی که چند روزی است که با سیستم کار می کنم، در ایالت های مختلف ماشین دارم. من همه آنها را در گروه Default دارم، اما امکان ایجاد گروه های جداگانه و انتقال ماشین به آنها در صورت نیاز وجود دارد. این بر هیچ چیز تأثیر نمی گذارد - فقط ارائه منطقی داده ها و گروه بندی آنها برای کار راحت تر. اولین و مهمترین کاری که بعد از این باید انجام دهیم این است که فرآیند مهاجرت را شروع کنیم. ما می توانیم این کار را به صورت دستی یا با تنظیم یک برنامه، از جمله به صورت انبوه برای همه ماشین ها به طور همزمان انجام دهیم.
اجازه دهید به شما یادآوری کنم که Hystax به عنوان یک محصول برای مهاجرت قرار گرفت. بنابراین، جای تعجب نیست که برای اجرای ماشین‌های تکراری خود باید یک طرح DR ایجاد کنیم. این طرح را می توان برای ماشین هایی که قبلاً در حالت Synced هستند انجام داد. شما می توانید هم برای یک ماشین مجازی خاص و هم برای همه ماشین ها به طور همزمان تولید کنید.
مجموعه پارامترها هنگام ایجاد طرح DR بسته به زیرساختی که به آن مهاجرت خواهید کرد متفاوت است. حداقل مجموعه ای از پارامترها برای محیط VMware در دسترس است. Re-IP برای ماشین ها نیز پشتیبانی نمی شود. در این رابطه، ما به نکات زیر علاقه مند هستیم: در توضیحات VM، پارامتر "subnet": "VMNetwork"، جایی که ماشین مجازی را به یک شبکه خاص در خوشه متصل می کنیم. رتبه - مربوط به هنگام مهاجرت چندین ماشین مجازی؛ ترتیب راه اندازی آنها را تعیین می کند. Flavor - پیکربندی VM را توصیف می کند، در این مورد - 1CPU، 2GB RAM. در بخش subnets تعریف می کنیم که "subnet": "VMNetwork" با VMware "VM Network" مرتبط است.
هنگام ایجاد یک طرح DR، هیچ راهی برای "گسترش" دیسک ها در حافظه های مختلف داده وجود ندارد. آنها بر روی همان دیتا استور تعریف شده برای این ابر کلاینت قرار خواهند گرفت و اگر دیسک هایی با کلاس های مختلف دارید، ممکن است هنگام راه اندازی دستگاه مشکلاتی ایجاد کند و پس از راه اندازی و "جداسازی" ماشین مجازی از Hystax، همچنین نیاز به یک دیسک مهاجرت جداگانه به دیتا استورهای مورد نیاز است. سپس تنها کاری که باید انجام دهیم این است که طرح DR خود را راه اندازی کنیم و منتظر بمانیم تا خودروهایمان بالا بیایند. فرآیند تبدیل P2V/V2V نیز به زمان نیاز دارد. در بزرگترین دستگاه تست من، 100 گیگابایت با سه دیسک، حداکثر 10 دقیقه طول کشید.
پس از این، باید VM در حال اجرا، خدمات روی آن، سازگاری داده ها را بررسی کنید و بررسی های دیگری را انجام دهید.
سپس دو راه داریم:
- حذف – طرح DR در حال اجرا را حذف کنید. این عمل به سادگی VM در حال اجرا را خاموش می کند. این کپی ها به جایی نمی رسند.
- جدا کردن - یک ماشین تکراری را از آکورا جدا کنید، یعنی. در واقع فرآیند مهاجرت را کامل کنید.
مزایای راه حل:
- سهولت نصب و پیکربندی هم از سوی مشتری و هم از ارائه دهنده؛
- سهولت راه اندازی مهاجرت، ایجاد یک طرح DR و راه اندازی نسخه های مشابه.
- پشتیبانی و توسعه دهندگان به سرعت به مشکلات پیدا شده پاسخ می دهند و آنها را با استفاده از به روز رسانی پلتفرم یا عامل برطرف می کنند.
منفی
- پشتیبانی ناکافی از Vmware
- عدم وجود هر گونه سهمیه برای مستاجران از سکو.
من همچنین یک درخواست ویژگی را گردآوری کردم که به فروشنده ارسال کردیم:
- نظارت بر استفاده و استقرار از کنسول مدیریت Acura برای عوامل Cloud.
- در دسترس بودن سهمیه برای مستاجران؛
- توانایی محدود کردن تعداد تکرارها و سرعت همزمان برای هر مستاجر.
- پشتیبانی VMware vCloud Director.
- پشتیبانی از منابع استخر (اجرا شده در طول آزمایش)؛
- توانایی پیکربندی عامل VMware از خود عامل، بدون وارد کردن اعتبار از زیرساخت مشتری در پنل Acura.
- "تجسم" فرآیند راه اندازی VM هنگام اجرای طرح DR.
تنها چیزی که باعث انتقاد شدید من شد، مستندات بود. من واقعاً «جعبه‌های سیاه» را دوست ندارم و ترجیح می‌دهم که اسناد دقیقی در مورد نحوه عملکرد محصول در داخل وجود داشته باشد. و اگر برای AWS و OpenStack محصول حتی کم و بیش توضیح داده شود، پس برای VMware مستندات بسیار کمی وجود دارد.
یک راهنمای نصب وجود دارد که فقط استقرار پنل Acura را توضیح می دهد و هیچ کلمه ای در مورد این واقعیت وجود ندارد که یک عامل Cloud نیز مورد نیاز است. مجموعه کاملی از مشخصات محصول وجود دارد که خوب است. اسنادی وجود دارد که تنظیمات را از ابتدا تا انتها با استفاده از AWS و OpenStack به عنوان مثال توصیف می‌کند (اگرچه برای من بیشتر شبیه یک پست وبلاگ است)، و یک پایگاه دانش بسیار کوچک وجود دارد.
به طور کلی، این کاملاً آن قالب مستندسازی نیست که من به آن عادت دارم، مثلاً از فروشندگان بزرگتر، بنابراین من کاملاً راحت نبودم. در عین حال، من هرگز پاسخی در مورد برخی از تفاوت های ظریف نحوه عملکرد سیستم "در داخل" در این اسناد پیدا نکردم - مجبور شدم بسیاری از سوالات را با پشتیبانی فنی روشن کنم و این روند استقرار جایگاه و انجام را کاملاً به تاخیر انداخت. آزمایش کردن.
به طور خلاصه، می توانم بگویم که به طور کلی محصول و رویکرد شرکت به کار را دوست داشتم. بله، کاستی هایی وجود دارد، کمبود عملکرد واقعاً حیاتی (در ارتباط با VMware) وجود دارد. واضح است که اول از همه، این شرکت هنوز روی ابرهای عمومی، به ویژه AWS متمرکز است و برای برخی این کافی است. امروزه که بسیاری از شرکت‌ها استراتژی چند ابری را انتخاب می‌کنند، داشتن چنین محصول ساده و مناسبی بسیار مهم است. با توجه به قیمت بسیار پایین تر نسبت به رقبا، این محصول را فوق العاده جذاب می کند.
ما به دنبال عضو تیم هستیم . شاید شما هستید؟
منبع: www.habr.com