Moving Server to VMs on the cloud on a different subnet

[token_toker]

שלום חברים,

 

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

כל האינפורמציה קיימת באילוסטרציה שצירפתי.

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

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

 

תודה מראש ואם ישנן שאלות תרגישו חופשי לשאול...

 

[Googleness]

אתה יכול לפרט מאיפה אתה עושה פינג לאיפה והאם אתה עושה פינג לפי כתובת או לפי שם?

 

[token_toker]

אני עושה פינג לכתובות לא ניתן לעשות פינגים לשמות.

פינג מהשרת הוירטואלי (רולים לא מוגדרים) 192.168.2.10 לכל הסאבנט הראשי 192.168.1.0 ולהפך.

[Googleness]

או קיי נתקדם הלאה,

אני אנחש שיש לך סביבת AD מבוססת שרתי Windows ומה שאתה רוצה לעשות זה Login או אימות כלשהו מול השרתים הוירטואלים?

איפה הDC שלך יושבים? (במקרה שאני מדויק).

 

[token_toker]

אני מתכוון להעביר את DC מה 192.168.1.0 ל- 192.168.2.0 כאשר המשתמשים ישארו על 192.168.1.0.

וכך גם להעביר את ה-Exchange ושאר השרתים.

כרגע כל האלמנטים יושבים על אותו סגמט.

 

[Googleness]

ובDNS של הקליינטים הם מפענחים את השם של השרת לכתובת הIP העדכנית שלו?

 

[token_toker]

לא.

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

[Googleness]

תעשה ככה למטרות הבדיקה,

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

 

תריץ בדיקה ותעדכן מה התוצאות.

[token_toker]

לא אמורה להיות בעיה, אבל אני אבדוק ואעדכן...

[multicore]

מה הבעיה להתגדיר static route אצלך בנתב שבנקודת יציאה?

[token_toker]

ברגע שהוספתי A record ב-dns של השרת המקומי/הפיזי אני מגיע בלי בעיה ל"שם המלא" של השרת הבדיקה הוירטואלי על הסאבנט 192.168.2.0.

יש לי את כל ה-static routes הנדרשים מוגדרים ותקינים אחרת ה-CP מפיל את החיבור בתואנה של address spoofing.

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

 

[Googleness]

אם הבנתי נכון את המצב מה שאתה צריך לעשות אחרי שאתה "מהגר" את השרתים שלך לוירטואלי על הסאבנט החדש תוודא שהDNS ב AD מעדכנים את הכתובות שלהם.

עכשיו תצטרך לבדוק בDHCP \ סטאטי של הכתובות בסאבנט הישן שהם מצליחים להגיע לDNS המעודכן או ליצור DNS נוסף (Secondary Zone) שישב בסאבנט הישן.

 

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

[token_toker]

אני מתכוון לעשות מיגרציה ושדרוג בשתי הופים לשרתים הפיזיים ל-VMs.

אני יודע ש-DHCP יכול לעבוד על סגמנט אחד וגם לשרת סגמנט אחר (multi scope) אם אני לא טועה.

מבחינת ה-DC, גם כן עד כמה שאני יודע, אין בעיה שהוא ישב על סגמנט אחד וישרת יוזרים על סגמנט אחר של הרשת אם מגדירים את ה-DNS וה-DHCP נכון.

 

הראוטר שיושב בצד של ה-VMs לא בשליטתי והייתי רוצה שהיציאה תהיה דרך הרשת הפיזית ולא דרך הוירטואלית, מה אני צריך לבקש מהספק? ניתוב הגייטויי שלהם אליי?

[Googleness]

אתה לא רוצה שהDC שלך יישב בענן בלבד.

DC לא אוכל כלום מבחינת משאבים וגם ככה הוא מגיע בד"כ עם DNS בפנים.

 

תגדיר לך DC אחד פיזי בתוך הארגון.

 

חלילה במקרה של תקלת תשתית \ תקלת ספק \ תקלת חשבונית (שכחתם לשלם לחברת האינטרנט) ואין לך DC בארגון וכל הארגון מושבת.

 

בקשר לDHCP אתה יכול להגדיר בראוטר שלך DHCP Relay שמפנה ל שרת ה DHCP עצמו. כידוע DHCP עובד ב Broadcast (מדברים על IPv4) וBroadcast לא יוצא מתוך הסגמנט\Vlan\Lan וכו'.

 

לסיכומו של דבר מה שאני הייתי ממליץ לך בהתחשב בעובדה שכבר יש לך שרת פיזי בארגון זה להגדיר DC\DNS\DHCP בארגון עצמו ובענן תגדיר לך DNS+DC נוסף.

מה שכן מה המהירות שלך בזירת הWAN? האם העובדה שאתה מרים שרתים בענן לא משפיעה על מהירות התקשורת בין השרתים לבין עמדות הלקוח?

יש לך הגדרה מובנית ה AD (דרך ה GP) שבמידה ומהירות החיבור מתחת ל500Kb\s זה נחשב Slow Link ודי הרבה דברים לא יעבדו.

 

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

שרת 1:

DC

DNS

DHCP

SQL

etc....

 

שרת 2:

DC

DNS

DHCP

SQL

etc....

 

כל שורה כזאת במכונה וירטואלית נפרדת (אלא אם מדובר ב DC+DNS וכולי שהולכים יחד). ואז במידה ומכונה אחת נופלת היוזרים לא מרגישים בחסרונה כי בשרת השני המכונה השניי לוקחת את העומס ומתחילה לעבוד. יש כל מיני תורות ותיאוריות בנושא הזה.

 

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

לא הייתי מעביר את כל הארגון לענן בלבד בלי גיבוי פיזי באתר.

[token_toker]

1. לא תהיה בעיה של זמינות השרתים הוירטואלים - חלק מהחוזה (SLA).

2. מודע לכל נושא הפיצ'פקעס של השרידות (אני שוקל להשאיר באתר שרת אחד פיזי שימלא כמה רולים ויתרפלק)

3. החיבור הוא גיגה ביט - אין בעית איטיות.

4. מודע גם ל-DHCP RELAY וגם לDHCP AGENT.

5. תודה רבה :)... עוררת לי כמה תהיות/התלבטויות שנשכחו מזמן.