אפשרות מעבר מסביבה של Storage אחד לשניים כאשר אחד מרוחק

sitepoint7

New member
אפשרות מעבר מסביבה של Storage אחד לשניים כאשר אחד מרוחק

היי

אני מעוניין להתחיל לשקול עבודה מול שני Storageים,

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

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

אודה אם תכוונו אותי למאמר בנושא
אולי לתת לי את המונחים הנכונים איתם לפחות אוכל להתחיל וללמוד/להבין את הנושא כפי שהוא עובד ומותאם לימינו

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

F00D Is G00D

New member
הי

לדעתי השאלה הראשונה היא הדרישות של הארגון. בעיקר
Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
&nbsp
אלו צריכים להייות נקודות ההתחלה שלמעשה ישפיעו על הפתרון מקצה אל הקצה. הייתי מאוד מציע לא לקבוע את אלו לפי שליפה מהמותן. לבדוק באמת כמה מידע אתם ייכולים להרשות לעצמכם להפסיד. וכמה זמן אפשר להישאר למטה ושעדיין בהשוואה לכדאיות הכלכלית של הפתרון (זה בסוף נקודת האיזוןן).
&nbsp
טכנולוגית - אני מעדיף שהפתרון יהיה ברמת האפליקציה (Exchange Replica, SQL always on, NLB front end servers) פתרון ברמת ההיפרוויזור . ייכול מאוד לסבך את ההתאוששות לעומת ייכולת built in של האפליקציה.
&nbsp
כחלק מבחינת הפתרון והעלויות. הייתי מציע לך לשמור על ראש פתוח בהחלפת פלטפורמת הוירטואליזציה.
&nbsp
לא חושב שאני ייכול לתת לך מאמר של ייטה אותך לפתרון כלשהו ועדיין ייתן לך מידע רלוונטי.....
 

sitepoint7

New member
אני כרגע בודק העניין תאורטית והשאלה הינה רק בנושא כתובות הIP

תודה על תגובתך!
ברור לי שהאופציה המועדפת הינה סנכרון בין שני ה STORAGEים (נטאפ במקרה שלי, מה שנקרא Snap Mirror)
ברור לי שהשרתים הפיזיים ועליהם ה VMware עובדים מול ה STORAGE מול POOL כתובות מסויים
ידוע לי שקיים ה SRM (היקר לטעמי) שיודע לעשות א' ב' ג'
ויש כמובן את ה vSphare Replication שיודע לעשות סינכרון גם ברמת ה STORAGE אך לא בצורה מושלמת/טבעית כמו שהמנגנון המובנה של ה STORAGE יודע
&nbsp
אני מתייחס אך ורק לנושא כתובות ה IP
למקרה שהאתר הראשי מת/הלך/נישרף ועכשיו אני צריך ללמוד/להתמודד עם נושא כתובות IP אחרות
&nbsp
יכול להיות שאני מפספס משהו בשאלה שלי עקב חוסר ידע או בילבוד,
אני מעלה את השאלה שלי בפורום הזה שהוא המתאים ביותר לטעמי והניסיון של האנשים יכול לעשות לי שכל או לפחות סדר
&nbsp
תודה
 

yossik111

New member
תרשה לי להביע דעה שונה / אחרת / תוספת .

ראשית , תלוי לדעתי מה מטרת הקמת הסטוראג השני (גיבוי (יחיד ?) / שרידות וכ'ו ) .
בכול מקרה , בתסריט של השבתת כול (והדגש כאן הוא על כול ) המערכת הווירטואלית המקומית , בהנחה שמדובר על אקטיב דיירקורי אכן , נראה לי דווקא שהתאוששות ברמת האפלקציה תהווה בעיה הרבה יותר גדולה מאשר התאוששת של כול המערכת לנקודת זמן x (כמובן בשאיפה קרובה ככול הניתן לנקודת זמן האסון (אפרופו הדיון שלך בנושא ה ה RTO וה PRO ).
לדעתי בהתאוששות כול המערכת לנקודת זמן X (סנפשוט) אתה צפוי להרבה פחות בעיות (אם בכלל) בנושא של סינכרון הזמנים כנגד האקטיב דיירקורי מאשר בהתאוששות תלוית אפלקציה (אם כול המשתמע מכך) , שלא לדבר על מהירות וצורת ההתאוששות שיכולה להיות ( עם אפליקציה מתאימה ( לפחות אמורה
)) מהירה / אוטומטית בהתאוששות כול המערכת לנקודת זמן X.
דעתי בלבד .
 

sitepoint7

New member
סבבה, הגישה שלך מקובלת ונכונה לדעתי אך אני עדיין...

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

F00D Is G00D

New member
אוקי

אופציות בנוגע לשמות \ כתובות:

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

2. נניח ואתה מתמודד עם חברה בגדילה, שאתה לא ייכול לצפות 10 שנים קדימה וייתכן - או שיש כרגע כמה חוות שרתים שהקשרים בינהם לא קשיחים (שוני בין החוות). רשת מסורתית היא כנראה הכרחית. לכל אתר צריך טווח כתובות ייחודי. והמעבר בתרחיש DR כדאי שייתבצע ברמת אפליקציה (שוב), באמצעות הפניות (CNAME) או רשומות DNS מרובות. Load balancers. וכ'ו.

3. נניח שיש מצב קיים. של מפעל - שני בניינים במרחק X אחד מהשני (המרחק הפיזי לא רלוונטי - יותר רלוונטי כמה שליטה יש לך על התקשורת ובעיקר השיהויי שלה). המפעל קיים כבר Y שנים, זה הנכסים שלו והא לא צופה שום שינוי דרמטי בקרוב. אז אפשר לחשוב על פתרונות כמו שרמזת עליהם - Stretch VLAN או אפילו פשוט LAN רחב. ככה שכתובת IP ייכולה לחיות בכל אחד מהאתרים. ניתן בצורה הזו להקים שני אתרים שהם active active ולאפשר לכל שירות לנדוד בקלות בין בסיסי הנתונים (למשל vmotion במקרה של vmware) . הזכרת NetApp – שימוש נכון ב NetApp עם תשתית כזו יהיה Metro Cluster, הנטאפ עצמו ייתפרס על שני האתרים כאילו הוא באחד. וישרת את הקליינטים בכל אתר ללא קשר בהימצאות הגיאוגרפית \ ה LANית

החסרון הוא בעיקר בייכולת שלך לגדול במצב הזה ולנהל את ה LAN בצורה שכזו. אתן דוגמא מקולגה שלי שהיה להם כמה Metro Cluster ( 7 מוד) עם רשת FCP וחוות שהם Active Active אבל מרוחקות 7 ק"מ אחת מהשנייה עם שיהויי ממוצע של מתחת 3ms
נוצר מצב שהמשתמש בבניין א. ניגש לשרת אפליקציה בבניין ב. שיוצא לאינטרנט דרך בניין א וגם ניגש ל SQL בבניין א. שניגש לסטורג' ול AD בבניין ב. רק 12ms נכון? אבל מה עם overhead? צריך להתחיל tcp sessions, לבדוק metadata מפה לשם – בנק עם חדר מסחר קיבל שיהוי בביצוע פעולות יום יומיות של כמעט שתי שניות (במקרה של מסחר – יש לזה השפעה אדירה). כאשר עשו את הפתרון ה"קל" באותו הרגע - והוא להפעיל הכל רק בבניין א. היו צריכים למעשה לוותר על חלק מהשרידות והאטומציה. (העברת הסטורג' לקונטרולר אחד פעיל, קינפוג של אחד הנתבים כ Passive. הכי גרוע – להתוכנן לכך שבעת אירוע בבניין א. ההתאוששות תהיה חייבת להייות הדרגתית. כי הסטורג' ייצטרך לעשות failover, ו AD לעלות באתר השני, ואז SQL, ואז אפליקציה וגם צריך להפוך את ה active - passive בין הראוטרים)

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

sitepoint7

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

אשמח לקבל את המלצתך האובייקטיבית האישית לצורת עבודה "נכונה" לדעתך ולדעתך בלבד בעבודה בשני אתרים כאשר אנחנו מדברים על
1. BCP - המשכיות עסקית ACTIVE ACTIVE
2. סביבת DR, כשמדובר ב DR בלבד

תשובה קצרה ועניינית בהחלט תספיק, תודה!
 
למעלה