ערפילית פתוחה. הערות קצרות

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

וכך, כפי שאנו רואים, ספקי ענן רבים עובדים על kvm ויוצרים חיבורים חיצוניים לשליטה במכונות. ברור שמארחים גדולים כותבים מסגרות משלהם לתשתית ענן, אותו YANDEX למשל. מישהו משתמש ב-openstack ויוצר חיבור על בסיס זה - SELECTEL, MAIL.RU. אבל אם יש לך חומרה משלך וצוות קטן של מומחים, אז אתה בדרך כלל בוחר משהו מוכן - VMWARE, HYPER-V, יש רישיונות בחינם ובתשלום, אבל לא על זה אנחנו מדברים עכשיו. בוא נדבר על חובבים - אלה שלא מפחדים להציע ולנסות משהו חדש, למרות שהחברה הבהירה בבירור, "מי ישרת את זה אחריך", "האם אנחנו הולכים לגלגל את זה לייצור מאוחר יותר ? מַפְחִיד." אבל אתה יכול קודם ליישם את הפתרונות האלה בספסל מבחן, ואם כולם אוהבים את זה, אז אתה יכול להעלות את השאלה של המשך פיתוח ושימוש בסביבות רציניות יותר.

כמו כן, הנה קישור לדוח www.youtube.com/watch?v=47Mht_uoX3A ממשתף פעיל בפיתוח פלטפורמה זו.

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

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

1. חזרה על התקנה

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

2. ניטור

ננטר את הצומת עצמו, kvm ו-opennebula. למרבה המזל, זה כבר מוכן. יש הרבה אפשרויות לגבי ניטור מארח לינוקס, אותו Zabbix או יצואן צומת - מי שיאהב מה יותר טוב - כרגע אני מגדיר את זה כמדדי מערכת ניטור (טמפרטורה שבה ניתן למדוד אותה, עקביות מערך הדיסקים), דרך zabbix , ולגבי יישומים דרך יצואן פרומתאוס. עבור ניטור kvm, למשל, אתה יכול לקחת את הפרויקט github.com/zhangjianweibj/prometheus-libvirt-exporter.git ולהגדיר את זה לפעול דרך systemd, זה עובד די טוב ומראה מדדי kvm, יש גם לוח מחוונים מוכן grafana.com/grafana/dashboards/12538.

לדוגמה, הנה הקובץ שלי:

/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter

[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"

[Install]
WantedBy=multi-user.target

אז יש לנו יצואן אחד, אנחנו צריכים אחד שני כדי לנטר את הערפילית הפתוחה עצמה, השתמשתי בזה github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

ניתן להוסיף לרגיל node_exporter כדי לפקח על המערכת את הדברים הבאים.

בקובץ node_exporter אנו משנים את ההתחלה כך:

ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collector

צור ספרייה mkdir -p /var/lib/opennebula_exporter

סקריפט bash שהוצג לעיל, ראשית אנו בודקים את העבודה דרך הקונסולה, אם היא מציגה את מה שאנחנו צריכים (אם הוא נותן שגיאה, אז התקן את xmlstarlet), העתק אותו אל /usr/local/bin/opennebula_exporter.sh

הוסף משימת cron עבור כל דקה:

*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)

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

(ברור שכאן אני מתחייב למעבד, RAM)

למי שאוהב ומשתמש ב- Zabbix, יש github.com/OpenNebula/addon-zabbix

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

עדיין לא ממש התחלתי לרשום. האפשרות הפשוטה ביותר היא להוסיף td-agent כדי לנתח את ספריית /var/lib/one עם ביטויים רגולריים. לדוגמה, הקובץ sunstone.log מתאים ל-nginx regexp ולקבצים אחרים המציגים את היסטוריית הגישה לפלטפורמה - מה היתרון בכך? ובכן, למשל, אנו יכולים לעקוב במפורש אחר המספר של "שגיאה, שגיאה" ולעקוב במהירות היכן ובאיזה רמה יש תקלה.

3. גיבויים

יש גם פרויקטים שהושלמו בתשלום - למשל ספטמבר wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. כאן עלינו להבין שפשוט גיבוי של תמונת מכונה אינו זהה כלל במקרה זה, מכיוון שהמכונות הווירטואליות שלנו חייבות לעבוד עם אינטגרציה מלאה (אותו קובץ הקשר שמתאר את הגדרות הרשת, שם ה-vm וההגדרות המותאמות אישית עבור היישומים שלך) . לכן, כאן אנחנו מחליטים מה ואיך נגבה. במקרים מסוימים עדיף לעשות עותקים של מה שיש ב-vm עצמו. ואולי אתה רק צריך לגבות דיסק אחד ממחשב נתון.

לדוגמה, קבענו שכל המכונות מתחילות עם תמונות מתמשכות, לכן, לאחר קריאה docs.opennebula.io/5.12/operation/vm_management/img_guide.html

זה אומר שקודם כל נוכל להעלות את התמונה מה-vm שלנו:

onevm disk-saveas 74 3 prom.qcow2
Image ID: 77

Смотрим, под каким именем он сохранился

oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
   
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.

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

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

4. קלות שימוש

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

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

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

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

5. פשטות מירבית

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

בתנאי העמדה שלי - 3 צמתים עם אחסון nfs - הכל עובד בסדר. אבל אם אנחנו עורכים ניסויים הכוללים הפסקת חשמל, למשל, כשמריצים תמונת מצב ומכבים את החשמל של הצומת, אנחנו שומרים הגדרות במסד הנתונים שיש תמונת מצב, אבל למעשה אין כזו (טוב, כולנו מבינים שאנחנו בתחילה כתב את מסד הנתונים על הפעולה הזו ב-sql , אך הפעולה עצמה לא הצליחה). היתרון הוא שביצירת תמונת מצב נוצר קובץ נפרד ויש "הורה", לכן במקרה של בעיות וגם אם זה לא עובד דרך gui, נוכל לאסוף את קובץ qcow2 ולשחזר אותו בנפרד docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

ברשתות, למרבה הצער, לא הכל כל כך פשוט. טוב, לפחות זה יותר קל מאשר ב-openstack, השתמשתי רק ב-vlan (802.1Q) - זה עובד די טוב, אבל אם תבצע שינויים בהגדרות מרשת התבניות, אז ההגדרות האלה לא יחולו על מכונות שכבר פועלות, כלומר. עליך למחוק ולהוסיף כרטיס רשת, ואז ההגדרות החדשות יחולו.

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

6. תוספים והתקנות נוספים

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

תמיכה עבור ספקי ענן אחרים מוצהרת docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

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

כמו כן, כעת יש לגרסה החדשה חזיז - זוהי ההשקה של microvm, סוג של רתמת kvm על docker, מה שנותן עוד יותר ורסטיליות, אבטחה ופרודוקטיביות מוגברת כי אין צורך לבזבז משאבים על חיקוי ציוד. היתרון היחיד שאני רואה על Docker הוא שהוא לא תופס מספר נוסף של תהליכים ואין שקעים תפוסים בעת שימוש באמולציה זו, כלומר. בהחלט אפשרי להשתמש בו כמאזן עומסים (אבל כנראה כדאי לכתוב על זה מאמר נפרד עד שאבצע את כל הבדיקות במלואן).

7. חוויה חיובית של שימוש ואיתור שגיאות

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

לדוגמה, פעולה פשוטה של ​​העתקת תמונת דיסק ממאגר נתונים אחד לאחר. במקרה שלי, יש 2 צמתים עם nfs, אני שולח את התמונה - ההעתקה מתרחשת דרך ה-frontend opennebula, למרות שכולנו רגילים לעובדה שצריך להעתיק נתונים ישירות בין מארחים - באותה vmware, hyper-v אנחנו רגיל לזה, אבל כאן לאחר. יש גישה אחרת ואידאולוגיה אחרת, ובגרסה 5.12 הסירו את כפתור "העבר ל-datastore" - רק המכונה עצמה מועברת, אבל לא האחסון בגלל פירושו אחסון מרכזי.

הבא היא שגיאה פופולרית מסיבות שונות: "שגיאה בפריסת מכונה וירטואלית: לא ניתן ליצור דומיין מ-/var/lib/one//datastores/103/10/deployment.5" להלן הדבר החשוב ביותר שיש להסתכל עליו.

• זכויות תמונה עבור משתמש oneadmin;
• הרשאות למשתמש oneadmin להפעיל את libvirtd;
• האם מאגר הנתונים מותקן כהלכה? לך תבדוק את הנתיב על הצומת עצמו, אולי משהו נפל;
• רשת מוגדרת לא נכונה, או ליתר דיוק ב-frontend זה בהגדרות הרשת שהממשק הראשי של vlan הוא br0, אבל בצומת זה כתוב כ-bridge0 - זה חייב להיות זהה.

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

8. תיעוד, קהילה. פיתוח עתידי

והשאר, תיעוד טוב, קהילה והעיקר שהפרויקט ימשיך לחיות גם בעתיד.

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

קהילה, פעיל. מפרסם פתרונות מוכנים רבים שתוכלו להשתמש בהם בהתקנות שלכם.

נכון לעכשיו, חלק מהמדיניות בחברה השתנו מאז 5.12 forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 יהיה מעניין לראות איך הפרויקט יתפתח. בהתחלה, ציינתי במיוחד כמה מהספקים שמשתמשים בפתרונות שלהם ומה התעשייה מציעה. כמובן, אין תשובה ברורה במה להשתמש. אבל עבור ארגונים קטנים יותר, תחזוקת הענן הפרטי הקטן שלהם עשויה להיות לא יקרה כמו שזה נראה. העיקר לדעת בדיוק מה אתה צריך.

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

יש צ'אט טוב t.me/opennebula הם עוזרים באופן אקטיבי ולא שולחים אותך לחפש פתרון לבעיה בגוגל. הצטרף אלינו.

מקור: www.habr.com