תכננתי לבלות את השבת בהכנה לדמו על SM-BC עבור לקוח שהוא גם חבר טוב אבל יצא שזה הרבה יותר פשוט ממה שחשבתי אז נשאר לי זמן לכתוב על זה ואולי גם את הקוראת החביבה תרוויחי.
SM-BC זה קיצור ל Snap Mirror Business Continuity. סנפמירור הוא פתרון הרפליקציה המובנה בכל מערכות NetApp ONTAP, הוא מאד ותיק, נפוץ, ומאד מוכר ולצידו במשך הרבה שנים היה לנטאפ פתרון בשם Metro-Cluster שאפשר להגדיר פתרונות המשכיות עיסקית מאד אגרסיביים. אם סנפ-מירור מאפשר רפליקציה ברמת ה Volume באופן א-סינכרוני או באופן סינכרוני, מטרו-קלאסטר מאפשר רפליקציה של מערכות אחסון שלמות ברמת הגנה RPO=0 ולבצע failover אוטומטי במקרה של כשל ברמת של כמעט RTO=0. עבור מרבית התרחישים הריאליים רמות ההגנה האלו טובות מספיק.
SM-BC הוא למעשה הפעם הראשונה בנטאפ מספקת מענה Active/Active טהור כלומר לראשונה נטאפ מאפשרת לייצג את אותו LUN בשתי מערכות פיזיות שונות הנמצאות במרחק של עד 700 קילומטר אחת מהשניה כאשר ה LUN זמין לקריאה וכתיבה בשני הצדדים בו-זמנית! מה שמתקבל כאן זה פתרון שמספק RPO=0 וגם RTO=0 ברמת מערכת האחסון, בחינם ובאופן קל ליישום, המגבלה היחידה היא מבחינת רוחב הפס וזמני התגובה על הקישור בין האתרים והאם האפליקציה והשרתים יודעים לתמוך בתצורה כזו אבל מבחינת מערכת האחסון אתם מוכנים לכל תרחיש! אגב, בעולם ה VMware למשל קיימת אינטגרציה מלאה לתצורת vSphere Metro Storage Cluster או vSMC.
שריל ג'ורג' מנהלת המוצר מספקת כאן דמו פשוט להבנה (מתנצל בשמה על איכות הסאונד):
שימו לב שהיא מסמלצת במסגרת הדמו IOPS באמצעות VDBench שעליו כבר כתבתי פעם אם מישהי חיפשה תזכורת.
בכל מקרה, SM-BC פועל ברמת Consistency Group שזה די הגיוני כי סביר להניח שאם יש לנו אפליקציה חשובה מספיק להגן עליה ברמת Active/Active היא תהיה מורכבת מיותר מאשר LUN בודד ובמקרה הפחות סביר שהיא דווקא כן בנויה מLUN בודד אז כמובן שאפשר להגדיר CG שמכיל רק LUN בודד.
אם אין לנו CG מוכן אז אפשר בתוך הוויזארד הסופר פשוט של SM-BC לייצר אותו אז בואו נראה איך עושים את זה. בתוך System Manager אנחנו בוחרים בצד שמאל protection ואז Overview ואז בצד ימין למטה לוחצים על Protect for Business Continuity:
בתוך האשף שנבחר כמו שאמרנו אפשר לבחור CG חדש
ואז בוחרים את ה Volumes שיהיו חברים ב CG ובוחרים את הSVM אליו אנחנו רוצים ליצור את הקשר SM-BC , לוחצים על Save וזהו!
תוך כמה שניות נוצר הקשר ותוך כמה דקות (או שעות במקרה של כמות מידע גדולה) הקשר יופיע בסטטוס Healthy In Sync שזה כמו n-Sync רק יותר מגניב.
כל מה שנשאר לנו לעשות זה למפות את ה LUN אל השרת גם דרך הנתיב החדש שנוצר לנו ולא לשכוח גם לעשות re-scan מצד השרת. בתוך הגדרות ה MPIO אפשר לראות שיש לנו נתיב אחד מוגדר כ Optimized והשני מוגדר Non-Optimized וזה כבר חלק מהקסם של ALUA או asymmetric logical unit access שמאפשרת לשרת ומערכות האחסון לתקשר באופן אוטומטי ולהחליט לעצמן בעצם מי מערכת האחסון הקרובה יותר, שהתקשורת אליה איכותית יותר והיא המערכת ה"ראשית".
אפשר להתערב בהגדרות ה ALUA אבל בדרך כלל ההגדרה האוטומטית שאומרת לשרת "זו מערכת האחסון הקרובה אליך אז תעדיף לעבוד מולה" היא אכן ההגדרה ההגיונית.
אז למי הפתרון הזה מתאים? בעצם לכולם, הוא לא דורש שום חומרה יעודית כמו שדרש מאיתנו מטרו-קלסטר, ממירי ATTO למשל, זוכרים? וגם לא נדרש שום רישוי מעבר ל Snap Mirror הרגיל והנפוץ. SM-BC מאפשר לנו בצורה קלה ונוחה בעצם להגדיר לכל סוג של מידע את רמת ההגנה הנדרשת עבורו, רפליקציה ברמה א-סינכרונית למידע פחות חשוב, רפליקציה סינכרונית למידע חשוב והגנה ברמת Active/Active מלאה עבור מערכות Mission Critical.
שלא תגידו שלא אמרתי!
כמו תמיד אשמח לשמוע מה חשבתן,
שלכם,
ניר מליק
ניר מליק 