Hystax Cloud Migration: Riding the Clouds

אחד השחקנים הצעירים בשוק פתרונות התאוששות מאסון הוא Hystax, סטארט-אפ רוסי ב-2016. מכיוון שהנושא של התאוששות מאסון פופולרי מאוד והשוק תחרותי ביותר, הסטארטאפ החליט להתמקד במעבר בין תשתיות ענן שונות. מוצר המאפשר לך לארגן העברה פשוטה ומהירה לענן יהיה שימושי מאוד עבור לקוחות Onlanta - משתמשים oncloud.ru. כך הכרתי את Hystax והתחלתי לבדוק את התכונות שלה. ומה יצא מזה, אספר במאמר זה.

המאפיין העיקרי של Hystax הוא הפונקציונליות הרחבה שלו לתמיכה בפלטפורמות וירטואליזציה שונות, מערכת הפעלה אורחת ושירותי ענן, מה שמאפשר להעביר את עומסי העבודה שלך מכל מקום ומכל מקום.

זה מאפשר לך ליצור לא רק פתרונות DR כדי לשפר את סבילות התקלות של שירותים, אלא גם להעביר במהירות ובגמישות משאבים בין אתרים שונים ו-hyperscalers כדי להגדיל את החיסכון בעלויות ולבחור את הפתרון הטוב ביותר עבור שירות מסוים כרגע. בנוסף לפלטפורמות המפורטות בתמונת הכותרת, החברה משתפת פעולה באופן פעיל עם ספקי ענן רוסים: Yandex.Cloud, CROC Cloud Services, Mail.ru ועוד רבים אחרים. כמו כן, ראוי לציין כי בשנת 2020 החברה פתחה מרכז מו"פ הממוקם בסקולקובו. 

הבחירה בפתרון אחד על ידי מספר רב של שחקנים בשוק מעידה על מדיניות תמחור טובה ועל ישימות גבוהה של המוצר, אותה החלטנו לבדוק הלכה למעשה.

אז, משימת הבדיקה שלנו תהיה מורכבת מהעברה מאתר הבדיקה שלי VMware וממכונות פיזיות לאתר של הספק שמריץ גם VMware. כן, יש הרבה פתרונות שיכולים ליישם הגירה כזו, אבל אנחנו מחשיבים את Hystax ככלי אוניברסלי, ובדיקת ההגירה בכל השילובים האפשריים היא פשוט משימה לא מציאותית. כן, והענן של Oncloud.ru בנוי במיוחד על VMware, כך שהפלטפורמה הזו, כיעד, מעניינת אותנו במידה רבה יותר. בהמשך, אתאר את עקרון הפעולה הבסיסי, שככלל אינו תלוי בפלטפורמה, וניתן להחליף את VMware מכל צד בפלטפורמה של ספק אחר. 

הצעד הראשון הוא פריסת Hystax Acura, שהוא לוח הבקרה של המערכת.

זה מתרחב מהתבנית. משום מה, במקרה שלנו, זה לא היה לגמרי נכון ובמקום ה-8CPU המומלץ, 16Gb נפרס עם חצי מהמשאבים. לכן צריך לזכור לשנות אותם, אחרת התשתית בתוך ה-VM, עליה הכל בנוי, פשוט לא תתחיל בקונטיינרים והפורטל לא יהיה זמין. IN דרישות פריסה המשאבים הנדרשים מתוארים בפירוט, כמו גם יציאות עבור כל רכיבי המערכת. 

והיו גם קשיים בהגדרת כתובת ה-IP דרך התבנית, אז שינינו אותה מהמסוף. לאחר מכן, תוכל לעבור לממשק האינטרנט של הניהול ולהשלים את אשף ההגדרה הראשוני. 

נקודת קצה - IP או FQDN של vCenter שלנו. 
כניסה וסיסמא - זה ברור כאן. 
שם המארח של Target ESXi הוא אחד המארחים באשכול שלנו שאליהם ישוכפלו. 
Target datastore הוא אחד ממאגרי הנתונים באשכול שלנו שאליהם ישוכפלו.
Hystax Acura Control Panel Public IP - הכתובת שבה לוח הבקרה יהיה זמין.

נדרשת הבהרה קטנה לגבי המארח ומאגר הנתונים. העובדה היא ששכפול Hystax עובד ברמת המארח ומאגר הנתונים. לאחר מכן, אני אגיד לך איך אתה יכול לשנות את המארח ואת מאגר הנתונים עבור הדייר, אבל הבעיה היא אחרת. Hystax לא תומכת באיגום משאבים, כלומר. העתק תמיד יקרה לשורש האשכול (בזמן כתיבת החומר הזה, החבר'ה מ-Hystax שחררו גרסה מעודכנת, שבה הם יישמו במהירות את בקשת הפיצ'רים שלי לגבי תמיכה במאגרי משאבים). גם vCloud Director אינו נתמך, כלומר. אם, כמו במקרה שלי, לדייר אין זכויות אדמין לכל האשכול, אלא רק למאגר משאבים ספציפי, ונתנו גישה ל-Hystax, אז הוא יוכל לשכפל ולהריץ את ה-VM האלה באופן עצמאי, אבל הוא יעשה זאת. לא יוכל לראות אותם בתשתית VMware, שאליה יש לו גישה ובהתאם, להמשיך לנהל מכונות וירטואליות. מנהל האשכול צריך להעביר את ה-VM למאגר המשאבים הנכון או לייבא אותו ל-vCloud Director.

למה אני מתמקד כל כך ברגעים האלה? מכיוון שלפי מה שאני מבין את הרעיון של המוצר, הלקוח אמור להיות מסוגל ליישם באופן עצמאי כל מיגרציה או DR באמצעות פאנל Acura. אבל עד כה, תמיכת VMware נמצאת מעט מאחורי רמת התמיכה באותו OpenStack, שבו כבר יושמו מנגנונים כאלה. 

אבל בחזרה לפריסה. קודם כל, לאחר ההגדרה הראשונית של הפאנל, עלינו ליצור את הדייר הראשון במערכת שלנו.

כל השדות כאן ברורים, אני אספר לכם רק על שדה הענן. יש לנו כבר ענן "ברירת מחדל" שיצרנו במהלך התצורה הראשונית. אבל אם אנחנו רוצים להיות מסוגלים לשים כל דייר במאגר הנתונים שלו ובמאגר המשאבים שלו, נוכל ליישם זאת על ידי יצירת עננים נפרדים עבור כל אחד מהלקוחות שלנו.

בצורה של הוספת ענן חדש, אנו מציינים את אותם פרמטרים כמו במהלך התצורה הראשונית (אנו יכולים אפילו להשתמש באותו מארח), מציינים את מאגר הנתונים הנדרש ללקוח מסוים, וכעת בפרמטרים הנוספים אנו כבר יכולים לציין בנפרד את משאב מאגר נדרש {"resource_pool" :"YOUR_POOL_NAME"} 

כפי שאולי שמתם לב, בצורת יצירת דייר אין על הקצאת משאבים או איזושהי מכסות - אין מזה כלום במערכת. לא ניתן להגביל את השוכר במספר העתקים בו-זמניים, במספר המכונות לשכפול או לפי כל פרמטר אחר. אז, יצרנו את הדייר הראשון. עכשיו יש דבר לא לגמרי הגיוני, אבל חובה - התקנת סוכן Cloud. זה לא הגיוני, כי הסוכן מוריד בעמוד של לקוח ספציפי.

יחד עם זאת, הוא אינו קשור לדייר שנוצר, וכל לקוחותינו יעבדו דרכו (או באמצעות כמה, אם נפרוס אותם). סוכן אחד תומך ב-10 הפעלות בו זמנית. מכונה אחת נספרת כהפעלה אחת. זה לא משנה כמה דיסקים יש לו. נכון להיום, אין מנגנון לסוכני קנה מידה ב-Acura עצמה תחת VMware. יש עוד רגע אחד לא נעים - אין לנו הזדמנות להסתכל על "סילוקו" של הסוכן הזה מהפאנל של Acura כדי להסיק אם אנחנו צריכים לפרוס יותר או שההתקנה הנוכחית מספיקה. כתוצאה מכך, הדוכן נראה כך:

השלב הבא לגישה לפורטל של הלקוח שלנו הוא יצירת חשבון (ותחילה, גם תפקיד שיחול על משתמש זה).

כעת הלקוח שלנו יכול להשתמש בפורטל באופן עצמאי. כל מה שהוא צריך לעשות זה להוריד סוכנים מהפורטל ולהתקין אותם בצד שלו. ישנם שלושה סוגים של סוכנים: Linux, Windows ו-VMware.

השניים הראשונים מוכנסים לפיזיקה או על מכונות וירטואליות בכל היפרוויזר שאינו VMware. כאן אין צורך בתצורה נוספת, הסוכן מוריד וכבר יודע היכן לדפוק, וממש בעוד דקה המכונית תהיה גלויה בפאנל של אקורה. עם סוכן VMware, המצב קצת יותר מסובך. הבעיה היא ש- Agent for VMware מורידים גם מהפורטל שכבר מוכן ויש לו את התצורה הדרושה. אבל סוכן VMware, בנוסף לדעת על פורטל ה-Acura שלנו, צריך לדעת גם על מערכת הווירטואליזציה שעליה הוא ייפרס.

למעשה, המערכת תבקש מאתנו לציין את הנתונים האלה כאשר אתה מוריד לראשונה את סוכן VMware. הבעיה היא שבעידן שלנו של אהבה אוניברסלית לאבטחה, לא כולם ירצו לציין את סיסמת המנהל שלו בפורטל של מישהו אחר, וזה די מובן. מבפנים, לאחר הפריסה, לא ניתן להגדיר את הסוכן בשום אופן (ניתן לשנות רק את הגדרות הרשת שלו). כאן אני צופה קשיים עם לקוחות זהירים במיוחד. 

אז, לאחר התקנת הסוכנים, נוכל לחזור ללוח אקורה ולראות את כל המכוניות שלנו.

מכיוון שאני עובד עם המערכת יותר מיממה, יש לי מכונות במצבים שונים. כולם נמצאים בקבוצת ברירת המחדל, אבל אפשר ליצור קבוצות נפרדות ולהעביר אליהן מכונות לפי הצורך. זה לא משפיע על שום דבר - רק הייצוג הלוגי של הנתונים והקיבוץ שלהם לעבודה נוחה יותר. הדבר הראשון והחשוב ביותר שעלינו לעשות לאחר מכן הוא להתחיל בתהליך ההגירה. אנחנו יכולים לעשות זאת גם באופן ידני בכוח וגם להגדיר לוח זמנים, כולל בכמויות גדולות עבור כל המכונות בבת אחת.

הרשו לי להזכיר לכם כי Hystax הוצב כמוצר להגירה. לכן, אין זה מפתיע שכדי להפעיל את המכונות המשוכפלות שלנו, עלינו ליצור תוכנית DR. אתה יכול ליצור תוכנית עבור מכונות שכבר נמצאות במצב מסונכרן. אתה יכול ליצור גם עבור VM ספציפי אחד, וגם עבור כל המכונות בבת אחת.

ערכת הפרמטרים בעת יצירת תוכנית DR תהיה שונה בהתאם לתשתית שאליה תעבור. סט מינימלי של אפשרויות זמין עבור סביבת VMware. גם Re-IP למכונות אינו נתמך. בהקשר זה, אנו מעוניינים בנקודות הבאות: בתיאור ה-VM, פרמטר "subnet": "VMNetwork", שבו אנו קושרים את ה-VM לרשת ספציפית באשכול. דירוג - רלוונטי בעת העברת מספר VMs, קובע את סדר ההשקה שלהם. Flavor מתאר את תצורת ה-VM, במקרה זה 1CPU, 2GB RAM. בסעיף רשתות המשנה, אנו מגדירים כי "רשת משנה": "VMNetwork" משויכת ל"רשת VM" של VMware. 

בעת יצירת תוכנית DR, אין דרך "לפצל" דיסקים בין מאגרי נתונים שונים. הם יהיו ממוקמים באותו מאגר נתונים שהוגדר עבור ענן הלקוח הזה, ואם יש לך דיסקים של מחלקות שונות, זה עלול לגרום לקשיים בעת הפעלת המכונה, ולאחר הפעלה ו"הפרדה" של ה-VM מה-Hystax, הוא גם יעשה דורשים דיסקי העברה נפרדים למאגרי הנתונים הנדרשים. אז אנחנו רק צריכים להפעיל את תוכנית ה-DR שלנו ולחכות שהמכוניות שלנו יעלו. תהליך ההמרה של P2V/V2V גם לוקח זמן. במכונת הבדיקה הגדולה ביותר שלי בנפח 100GB עם שלושה דיסקים, זה לקח לכל היותר 10 דקות.

לאחר מכן, עליך לבדוק את ה-VM הפועל, השירותים עליו, עקביות הנתונים ובדיקות אחרות. 

לאחר מכן יש לנו שתי אפשרויות: 

1. מחק - מחק תוכנית DR פועלת. פעולה זו פשוט תכבה את ה-VM הפועל. ההעתקים האלה לא הולכים לשום מקום. 
2. ניתוק - לקרוע את המכונית המשוכפלת מאקורה, כלומר. למעשה להשלים את תהליך ההגירה. 

יתרונות הפתרון: 

• קלות ההתקנה והתצורה הן בצד הלקוח והן בצד הספק; 
• קלות הגדרת הגירה, יצירת תוכנית DR והשקת העתקים;
• תמיכה ומפתחים מגיבים די מהר לבעיות שנמצאו ומתקנים אותן באמצעות עדכוני פלטפורמה או סוכן. 

חסרונות 

• תמיכת Vmware לא מספקת.
• היעדר כל מכסה לדיירים מהפלטפורמה. 

עשיתי גם בקשת Feature, אותה העברנו לספק:

1. ניטור ופריסה של שימוש מ-Acura Management Console עבור סוכני ענן;
2. זמינות מכסות לדיירים; 
3. היכולת להגביל את מספר השכפולים והמהירות בו זמנית עבור כל דייר; 
4. תמיכה ב-VMware vCloud Director; 
5. תמיכה במאגרי משאבים (יושם במהלך בדיקות);
6. היכולת להגדיר את סוכן VMware מהצד של הסוכן עצמו, מבלי להזין אישורים מתשתית הלקוח בפאנל Acura;
7.  "ויזואליזציה" של תהליך התחלת VM בעת התחלת תוכנית DR. 

הדבר היחיד שגרם לי לתלונות גדולות היה התיעוד. אני לא ממש אוהב "קופסאות שחורות" ומעדיף כשיש תיעוד מפורט על איך המוצר עובד בפנים. ואם עבור AWS ו-OpenStack המוצר מתואר אפילו פחות או יותר, אז עבור VMware יש מעט מאוד תיעוד. 

ישנו מדריך התקנה שמתאר רק את הפריסה של פאנל Acura, והיכן אין מילה על הצורך בסוכן ענן. יש סט שלם של מפרטים למוצר, וזה טוב. יש תיעוד שמתאר את ההגדרה "מ-ואל" באמצעות AWS ו-OpenStack כדוגמה (למרות שזה מזכיר לי יותר פוסט בבלוג), ויש מאגר ידע קטן מאוד. 

באופן כללי, זה לא בדיוק פורמט התיעוד שאני רגיל אליו, למשל, מספקים גדולים יותר, אז לא היה לי לגמרי נוח. יחד עם זאת, לא מצאתי תשובות לגבי כמה מהניואנסים של פעולת המערכת "בפנים" בתיעוד הזה - נאלצתי להבהיר הרבה שאלות עם תמיכה טכנית, וזה די גרר את תהליך פריסת העמדה ו בדיקה. 

לסיכום, אני יכול לומר שבאופן כללי אהבתי את המוצר ואת הגישה של החברה לביצוע המשימה. כן, יש פגמים, יש חוסר ממש קריטי בפונקציונליות (בשילוב עם VMware). ניתן לראות שקודם כל, החברה עדיין מתמקדת בעננים ציבוריים, בפרט AWS, ולחלק זה יספיק. מוצר כל כך פשוט ונוח כיום, כאשר חברות רבות בוחרות באסטרטגיית מולטי ענן, חשוב ביותר. לאור המחיר הנמוך בהרבה בהשוואה למתחרים, הדבר הופך את המוצר לאטרקטיבי ביותר.

אנחנו מחפשים צוות מהנדס ראשי של מערכות ניטור. אולי זה אתה?

מקור: www.habr.com