במהלך גיבוי, נשלחים כמויות גדולות של נתונים דרך הרשתות, מושפעות אופרציות עסקיות עיקריות בסביבת הייצור. מנהלי הרשת משתמשים בשיטות שונות כדי להפחית את ההשפעה של גיבויים על הפעולות היומיומיות. אלה כוללות קביעת זמני גיבויים מחוץ לשעות העסקים ושימוש בטכניקות להפחתת תעבורת כמו דחיסת נתונים וגיבויים חלקיים. אך, אחת מהדרכים הטובות ביותר לייעל את תעבורת הגיבוי היא ההפרדה בין רשתות הייצור והגיבוי. ואחת מהשיטות האפשריות לעשות זאת היא גיבוי ללא LAN.
בפוסט זה, אנו מדריכים אותך דרך שתי השיטות הכי נפוצות לגיבוי LAN-Free המשמשות בסביבות וירטואליות של VMware: גישה ישירה ל-SAN ו-HotAdd. נסביר גם איך NAKIVO Backup & Replication, פתרון גיבוי ושחזור אסונות מקיף, משתמש בשיטות אלה לגיבוי ומסירת VM יעילה יותר.
שיטות ההעברה בלי LAN ב-VMware
VMware מספקת שיטות העברת נתונים מרובות להעתקת נתונים מתקליטורי הווירטואלי של VM בעת יצירת גיבויי תמונה. שיטות אלו מאפשרות ליישומי גיבוי להעתיק נתונים בדרך הרציונאלית ביותר כדי להשיג מהירויות העברת נתונים גבוהות יותר והעמסה נמוכה על החומרה הייצורית.
כאשר מתבצעת העתקת נתונים דרך רשת מקומית (LAN), משמשים מצבי העברת NBD (התקן למכשיר בלוק רשת) ו-NBDSSL (NBD עם SSL). אך, בפוסט הזה, אנו מתעסקים בשיטות העברת בלי LAN כמו גישה ישירה ל-SAN ו-HotAdd. שיטות אלו מאפשרות לתוכנת גיבוי לקרוא נתונים ישירות מאחסון המחובר למארחי ESXi ולעבור על תשתיות הרשת.
כדי לגשת לאחסון ישירות, יישומי מודעי אחסון כגון תוכנות גיבוי משתמשות ב- API של vSphere להגנת נתונים (VADP) ובמערכת פיתוח דיסקים וירטואליים (VDDK) שסופקה על ידי VMware. זה מאפשר לאפליקציות אלו להעביר נתוני מכונה וירטואלית בדרך המשאבית ביותר וללא צורך בהתקנת סוכנים על המכונות המקוריות.
שיטת גיבוי ללא רשת 1: גישה ישירה ל-SAN
A storage area network (SAN) is a network of disk drives set up as a single entity. Servers in a SAN have access to the storage capacities in this shared pool of storage drives without being tied to a specific HDD or SSD.
פיזית, מערכות אחסון, שרתים ומתגים ב-SAN יכולים להיות מחוברים באמצעות כבלי Fibre Channel או Ethernet. העברת נתונים בתוך ה-SAN ניתן ליישם באמצעות פרוטוקולי iSCSI, Fibre Channel או Fibre Channel על Ethernet. בתוך ה-SAN, כל מכשיר אחסון (פיזי או וירטואלי) מקבל מספר יחיד לוגי ייחודי (LUN) לזיהויו, וה-LUN הזה משמש לחיבור המכשיר לשרת. נתונים בתוך ה-SAN זורמים בלי לצאת ל-LAN, וגישה ישירה ל-SAN משתמשת בכך כדי לעקוף את ה-LAN בעת העתקת נתונים למאגר גיבוי.
בדרך כלל, מנהלי מערכות משתמשים ב-SAN כדי לשפר את יעילות אחסון הנתונים, הגמישות והגיבוי. על ידי חיבור LUN/מכשיר ליותר משרת אחד, ניתן לוודא המשך פעילות העסק. גם אם השרת הראשי נופל, הנתונים לא יאבדו מכיוון שאפשר להחליף לשרת אחר.
איך גישה ישירה ל-SAN עובדת
בעת השימוש בגישת גישה ישירה ל־SAN בסביבות VMware, היישום לגיבוי קורא נתונים ישירות מ־LUN בו הדיסק הווירטואלי של ה-VM המקורי ממוקם, מבלי להעביר אותו דרך המארחים של ESXi או דרך ה-LAN. על מנת לעשות זאת, עליך להתקין גשש גיבוי על מכונה פיזית המחוברת ל־SAN דרך כמויות הנתונים באמצעות רשת האחסון (ניתן גם להיות מכונה וירטואלית המחוברת ל־SAN datastore). גשש גיבוי הוא רכיב ביישום הגיבוי שמעביר נתוני VM של VMware בין המקור למאגר הגיבוי. בתרשים למטה, הגשש גיבוי מיוצג כ־יישום גיבוי.
הערה: יישום הגיבוי משתמש ב-API של הדיסק הווירטואלי וב־Virtual Disk Development Kit (VDDK), שמסייעים בקבלת מידע על הגדרת ה־LUN ובגישה אל דיסקים ווירטואליים של VM. באמצעות ספריית ה־VMware VDDK, הגיבוי יכול להיות ללא סוכן לחלוטין, כך שתהליך הגיבוי לא משפיע על ההתאם של נתוני המקור או משפיע על הפעולות הרצות עליו. אחסון הגיבוי מחובר למכונה עליה מופעל היישום לגיבוי.
יתרונות
- מצב ההעברה ישירה מתוך SAN הוא הדרך המהירה ביותר לגבות VM של VMware המוצבים על מארחי ESXi המחוברים ל־SAN. מצב זה גם מפחית את העומס על רשתות הייצור ועל החומרה.
אילוצים
- A backup application (the backup proxy component) must be installed on either a physical server connected to the SAN or a VM running on the ESXi host physically connected to the SAN. Note that the ESXi host running the VM with the backup application must be a standalone ESXi host. This means that the ESXi host must not be managed by vCenter Server, whose inventory (that is, the VMs managed by this vCenter Server) you want to back up.
- מצב העברת SAN אינו עובד עם VMware vVols ו VMware vSAN. הביצועים טובים יותר עבור דיסקים וירטואליים מוחלקים בצורה מלאה כאשר משחזרים מכונות וירטואליות באמצעות מצב העברת SAN.
- כלי VMware חייבים להיות מותקנים על מנת להשתמש בתכונות כגון הוספת מכשירים לחם ו צילומי צילום דקות (צילומי יישום) לגיבוי נתונים.
- מצב העברת SAN עובד עם מכשירי אחסון שניתן לגשת אליהם כ-LUN ברמת הנהג (ולא ברמת המערכת הקובץ, כגון NTFS או EXT4). יש לגשת אל LUN כמכשיר גלמי.
וודאו שמערכת ההפעלה שבה מותקן היישום לגיבוי (או פרוקסי גיבוי) אינה מאתחלת (מחתמת מחדש) נפח SAN עם מערכת קבצים VMFS . VMFS אינה נתמכת במערכות הפעלה אחרות מ-ESXi, ואתחול כזה עשוי להפוך נפח VMFS לבלתי קריא על ידי מארח ESXi. ייתכן שתצטרכו לערוך הגדרות מדיניות SAN במערכת הפעלה שבה מותקן היישום לגיבוי. מאתחל המבצע iSCSI חייב להתחיל במכונה זו כדי לגשת ל-LUN ב-SAN דרך iSCSI.גישה ישירה ל-SAN ב-Nakivo Backup & Replication
ודא שמערכת ההפעלה שבה מותקן אפליקציית גיבוי (או פרוקסי גיבוי) לא מאתחלת (מחתימה מחדש) כרום SAN עם מערכת קובץ VMFS. VMFS אינה נתמכת במערכות הפעלה שונות מ-ESXi, ומאתחל כזה עשוי להופות על כך שנפגעת קריאות הנתונים בנפח VMFS על ידי מארח ESXi. עשוי להיות צורך לערוך הגדרות מדיניות SAN במערכת ההפעלה שבה מותקנת אפליקציית גיבוי. יש להפעיל את המאתחל iSCSI במחשב זה כדי לגשת ל- LUN ב-SAN דרך iSCSI.
גישה ישירה ל-SAN ב- NAKIVO Backup & Replication
NAKIVO Backup & Replication היא פתרון להגנת נתונים המיועד להגנת נתונים יעילה בסביבות VMware vSphere. הפתרון משתמש ב- API של VMware כדי ליצור גיבויים מבוססי תמונה ללא סוכן כמו גם בטכנולוגיות טבעיות של VMware כמו Changed Block Tracking (CBT) ומצבי העברת נתונים ללא LAN להגנת נתונים יותר יעילה.
ניתן להשתמש במצב גישה ישירה ל-SAN בעת יצירת גיבוי VM של VMware vSphere בפתרון NAKIVO. ה- Transporter הוא הרכיב האחראי על העברת נתונים מסביבות vSphere לאחסון גיבוי, שכפול VM בין מארחי ESXi וכו ', והמנהל הוא הרכיב שמספק את ממשק האינטרנט. ה- Transporter פועל כפרוקסי גיבוי, לשימוש במונחי ההעברה של VMware. ניתן להתקין את פתרון NAKIVO על מחשב פיזי או כמכשיר יישום וירטואלי של VMware vSphere על VM.
שיטת גיבוי ללא LAN: HotAdd
הערה: כפיל מקושר הוא העתק של מכונה וירטואלית שנוצר מקטע הזיכרון של המקור המכונה הוירטואלית. כפיל מקושר משתף את הדיסק הוירטואלי של המקור (נקרא גם אב) עם היכולת לכתוב נתונים חדשים לדיסק המשתנה שנוצר עם הקטע.
הפעלת אפליקציית גיבוי (או פרוקסי גיבוי) על מכונה וירטואלית כמכשיר וירטואלי מספקת לך את היתרון של להחביר דיסק וירטואלי ישירות למכונה היעד הזו. החיבור של דיסק הוירטואלי יכול להתבצע לאחר יצירת הקטע של מקור המכונה. במקרה זה, מכונת היעד (עם אפליקציית הגיבוי) יכולה לקרוא את תוכן דיסק הוירטואלי של הכפיל המקושר ולהעתיק נתונים ליעד הגיבוי.כאשר מופעל מצב HotAdd, פתרון גיבוי יכול לקרוא נתוני מכונה וירטואלית ישירות ממאגרי הנתונים של המכונה דרך מערכת I/O האחסון, דוחפת את מערכת ה-TCP/IP של המארח הייתה תופעתית תופעתית את כל מכונה וירטואלית המארחת על השרת ואיטתה את ההעברת הנתונים.
מצב ההעברה הזה בדרך כלל משמש כאשר אין גישה ישירה ל-SAN, לדוגמה, אם פשוט אינך משתמש בהתקן SAN. HotAdd מספק תמיכה כמעט זהה כמו גישה ישירה ל-SAN, אך יש לו גבולות גם.
צורת ההעברה הזו נהוגה בדרך כלל כאשר אין גישה ישירה ל-SAN, לדוגמה, אם פשוט אין לך מכשיר SAN. HotAdd מספק תמיכה כמעט זהה לגישה ישירה ל-SAN, אך יש בה גם הגבלות.
הגבלות
- יש להתקין את אפליקציית הגיבוי על מכונה וירטואלית כדי לאפשר תיק וירטואלי להיות מחובר אליה.
- המכונה הווירטואלית שבה מותקנת אפליקציית הגיבוי חייבת לקבל גישה ישירה לאחסון שבו המכונה הווירטואלית המקורית ממוקמת. האחסון יכול להיות אותו דיסק פיזי אם אפליקציית הגיבוי והמכונה הווירטואלית המקורית נמצאות על אותו מארח. אחסון זה יכול גם להיות אחסון משותף, כמו NAS או אפילו SAN.
- צורת ההעברה HotAdd אינה נתמכת עבור תיקי וירטואליים המחוברים למכונות וירטואליות דרך בקר דיסק וירטואלי IDE. תיקים וירטואליים חייבים להיות מחוברים למכונה וירטואלית דרך בקר דיסק וירטואלי SCSI. דיסקים SCSI תומכים ב-hot add/hot plug, בעוד שדיסקים IDE אינם תומכים בתכונה זו. מומלץ להשתמש בבקר SCSI פרה-ווירטואלי.
- המספר המרבי של תיקי וירטואליים שניתן לצרוב לבקר SCSI וירטואלי למכונות וירטואליות של VMware הוא 15. אם מספר התיקים הווירטואליים שאתה צריך לגבות בו זמנית עולה על המגבלה (שים לב שלפחות תיק וירטואלי אחד משמש את פתרון הגיבוי לריצה), עשוי להיות צורך להוסיף עוד בקר דיסק SCSI וירטואלי אחד.
איך עובד צורת ההעברה HotAdd
למטה תוכל לראות תרשים עם שני מארחי VMware ESXi ומכונות וירטואליות הרצות עליהם. שני מארחי ESXi מחוברים לאחסון משותף דרך הרשת האחסון ול-LAN (רשת היצור).
- יישום הגיבוי (גיבוי פרוקסי) מבקש יצירת צילום מקור של הדיסק הוירטואלי המקורי (.vmdk) של המכונה הוירטואלית לצורך גיבוי (בין אם גיבוי דיסק או גיבוי עם תיאום יישומים) ויצירת קלון מקושר. היישום משתמש ב- API הדיסק הוירטואלי ו-VDDK עם VixTransport ו-VixDiskLib כדי לטפל בקלון המקושר.
- הדיסק הוירטואלי הזה שנמצא על האחסון של ESXi מוסיף חם למכונה היעד עם יישום הגיבוי, שגם יש לו גישה לאותו אחסון של ESXi. ניתן לשתף את אחסון ESXi (כפי שמוצג בתרשים למטה).
- יישום הגיבוי מעתיק נתוני דיסק וירטואלי מהדיסקים המחוברים אליו מבלי להשתמש ברשת היצור (LAN בתמונה למטה).
- לאחר שהתהליך של הגיבוי הושלם, הדיסק הוירטואלי מנתק והצילום מוחק.
הערה: בדיוק כמו במצב גישה ישירה ל-SAN, גיבוי המכונה הוירטואלית הוא חסר סוכן בעת השימוש במצב ההעברה HotAdd.
HotAdd ב-Nakivo Backup & Replication
כפי שציינו לעיל, הפתרון של NAKIVO מאפשר לך לשמור על היתרונות של וירטואליזציה עם גיבוי ושחזור המסתמכים על ג'יקומייל APIs וטכנולוגיות נייטיביות לגיבויים מהירים ויעילים יותר מבחינת משאבים. בנוסף לאפשר לך להשתמש בגישה ישירה לSAN להגנת נתוני VMware vSphere, הפתרון יכול להשתמש בטכנולוגיית HotAdd כדי לעקוף את ה-LAN ולפנות משאבי ייצור.
התרשים הבא מראה איך NAKIVO Backup & Replication מפעיל גיבוי של מכונה וירטואלית של VMware באמצעות מצב HotAdd להעברת נתונים ללא שימוש ב-LAN. המעביר, רכיב הפתרון האחראי על העברת נתונים, פועל כהספק גיבוי. כל המכונות הווירטואליות בדוגמה זו ממוקמות באותו מארח ESXi.
- צילומי-מסך של דיסקים של מכונות וירטואליות מקור או יעד מחוברים למכונה עם המעביר המותקן באמצעות VADP ו-VDDK (מכונה יעד היא עותק של מכונה וירטואלית או מכונה וירטואלית אליה אנו משחזרים נתונים). המעביר יכול להיות מחובר למעביר אחר המותקן במחשב עם ספריית גיבוי.
- הנתונים מועתקים בלי שימוש ב-LAN.
- לאחר שהמשימה הושלמה, צילומי-הדיסקים הווירטואליים מופרדים מהמכונה עם המעביר.
דוגמה לגיבוי ללא שימוש ב-LAN: HotAdd עם הפתרון של NAKIVO
להבין טוב יותר כיצד מתבצע גיבוי ברשת מקומית חופשית בתוכנת גיבוי, בואו נסתכל על דוגמה של משימת גיבוי אמיתית ב-NAKIVO Backup & Replication. בדוגמה זו, אנו משתמשים במארח ESXi אחד שננהל על ידי vCenter, מכונת וירטואלית עם הפתרון של NAKIVO מותקן (כל רכיבי הפתרון כולל המוביל מותקנים על אותה מכונה וירטואלית), ושרת Windows Server 2019 VM שברצוננו לגבות (Win19-02). שני ה-VM ממוקמים ב- datastore אחד המחובר למארח ESXi.
בפתרון NAKIVO, ניתן לבחור את מצב ההעברה באשף יצירת משימת גיבוי VMware. ניתן לבחור את מצב ההעברה באופן אוטומטי, או להגדירו באופן ידני (אוטומטי הוא האפשרות המוגדרת כברירת מחדל). הגדרות ה-VMware vSphere שלנו תומכות במצב HotAdd לגיבוי VM ברשת מקומית חופשית.
בואו נתחבר ללינוקס שמותקן על מכונת הווירטואלית של הפתרון NAKIVO ונבדוק סוגי יחידות אחסון בלוק שמחוברות למכונה זו באמצעות הפקודות הבאות:
ls /dev/disk/by-path
lsblk
זכור את היחידות האחסון בלוק שמחוברות לפני הרצת משימת הגיבוי (ראה תמונה מצורפת למטה).
- sda היא דיסק מערכת עם שני מחיצות.
- sdb משמש למאגר גיבוי מובנה.
- sr0 הוא כונן דיסק DVD וירטואלי.
כשאנחנו מריצים את העבודת הגיבוי, אנחנו רואים שהמצב המעבר החם-הוסף (HotAdd) נבחר עבור גיבוי ה-VM ללא רשת.ה-VM שאנחנו מגיבים עליו באחד הדיסקים המדומים, בערך בגודל 40 ג'יגה-בא. החלק המשתמש בדיסק הזה הוא 18.1 ג'יגה-בא.
בזמן שהעבודת הגיבוי מתרחשת, אנחנו בדוגמה נבדוק מחדש את המכשירים הבלוק המחוברים למערכת הוירטואלית הבסיסה על Linux בעזרת אותם הפקים.
ניתן לומר שנוסף מכשיר בלוק חדש. זה בגלל שניתן סקירה זמנית של ה-VM המקורי (ה-VM שאנחנו מגיבים), והיא מחוברה למערכת הוירטואלית הבסיסה כדיסק SCSI עם תכונת ה-VMware HotAdd.
הדיסק SCSI המחובר הזה בשם sdc מכיל 5 חלקים. ניתן לראות שהגודל של הדיסק הוא 40 ג'יגה-בא, שזה אותו הגודל שבדקנו קודם בממשק האינטרנט בזמן ניהול העבודת הגיבוי.
אם נפתחים VMware vSphere Client, נוכל לראות את הסקירה הזמנית הנוצצת עבור ה-VM Win19-02 שאנחנו מגיבים. יש תיאור לסקירה עם מידע על היישום שגירם ליצירתה.
יש גם קבצים זמניים שנאחדים בתיקיון עם קבצי ה-VM של המערכת הגיבות NAKIVO. הקבצים האלה קשורים לסקירה הוירטואלית המוצגת עבור גיבוי ה-VM עם האפשרות HotAdd במצב המעבר החם-הוסף.
אחרי שהעבודת הגיבוי ה
Source:
https://www.nakivo.com/blog/benefits-technologies-lan-free-backup/