ההבדלים בין Azure classic deployment לבין-Azure resource manager (ARM) deployment

azure-migration-classic-to-arm

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

Azure classic deployment מכונה גם Azure service manager (ASM)

Azure resource manager (ARM) deployment

כל מי שעבד עם השירות של Azure מימיו הראשונים למעשה עבד עם "הפורטל הישן", פרס וניהל את המשאבים שלו ב-Azure בשיטה היחידה שהייתה קיימת עד ינואר 2015  – Azure classic deployment.
בינואר 2015 מיקרוסופט פתחה לציבור את הגישה ל-"פורטל החדש" של Azure ואיתו הגיע שיטת פריסה (Deploy) נוספת – Azure resource manager (ARM) deployment ששונה באופן מהותי מהשיטה שהייתה קיימת עד כה.
מהנקודה הזו של ינואר 2015 התעוררו למשתמשים שאלות רבות בנושא, כמו,
מה זה Azure resource manager (ARM) ?
כיצד עובד Azure resource manager (ARM) ?
מה ההבדלים בין שיטות הפריסה ?
מה היתרונות של השיטה החדשה ARM על פני השיטה הישנה  classic deployment ?
האם התמחור של המשאבים שונה בין שיטה לשיטה ?
האם ניתן להמיר משאבים שנפרסו ב- classic deployment ל-ARM ?
למה צריך שתי שיטות פריסה וניהול ?
בפוסט הזה אסביר ואענה על כל השאלות הנ"ל וקצת מעבר… המטרה, להותיר אתכם ללא שאלות בסיום הקריאה.

יאללה כנסו, מתחילים!

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

ועכשיו, שימו לב לעובדה חשובה, שירותים שנפרסו באמצעות classic deployment תוכלו להמשיך לנהל אותם רק בשיטה הזו, אם נפרסו באמצעות ARM תוכלו להמשיך לנהל אותם רק בשיטת ARM.
כמו כן, לא ניתן לשלב בין שירותים שנפרסו באמצעות classic deployment לבין שירותים שנפרסו באמצעות ARM.
לדוגמא, שרת וירטואלי שהוגדר ב- classic deploymentלא יוכל לשבת בתוך Virtual network שהוקמה ב-ARM.
כאשר אתם נכנסים לפורטל החדש מיד תוכלו להבחין בין שירותים שנפרסו ומנוהלים באמצעות classic deployment לבין שירותים שנפרסו ומנוהלים ב-ARM כיצד תבחינו ?
שירותים שנפרסו באמצעות classic deployment ליד שם השירות יופיע בסוגריים הסימון (classic) לעומת זאת שירותים המנוהלים באמצעות ARM הסימון הזה לא יופיע. ראו את צילום המסך הבא מתוך הפורטל החדש:

01

כעת נסקור את המאפיינים העיקריים וצורת העבודה של כל אחת משיטות ה-Deployment ולאחר מכן נדגיש את היתרונות של ARM לעומת classic deployment

Classic deployment

ניהול מבוזר של המשאבים המרכיבים את ה-"פתרון"/שירות/אפליקציה.
אסביר, נניח והפתרון שלכם הוא אתר אינטרנט שמשמש כלוח מכירות יד שניה.
השירותים שמרכיבים את הפתרון שלכם במקרה הזה הם:
– שני שרתי WEB המארחים את ה-Front של האפליקציה, יושבים בתוך Cloud service ועובדים בתצורה של Load balancing.
– שני שרתי WEB המארחים את המערכת ה-Back office \ CMS של האפליקציה, יושבים בתוך Cloud service ועובדים בתצורה של Load balancing.
– שני שרתי SQL העובדים בתצורה של SQL mirroring ויושבים בתוך Cloud service ומארחים את הDB של האפליקציה.
– שירות Azure SQL  (DB as a service) שמארח DB שבו נשמרים הפרטים של המשתמשים שנרשמו ל-Newsletter באתר.

הממשק וצורת העבודה של classic deployment לא מאפשרים להבין שיש קשר בין כל המשאבים הנ"ל ושהם למעשה רכיבים שמרכיבים פתרון אחד – אתר אינטרנט/האפליקציה שלכם.
כפועל יוצא מזה צורת הניהול לא מאפשרת ניהול מרוכז של הפתרון, כפתרון. אלא כל רכיב/שירות בפתרון מנוהל בנפרד בכל היבט.
נניח ונרצה למחוק את הפתרון, לא נוכל למחוק את כל השירותים המרכיבים אותו בבת אחת. נאלץ למחוק תחילה את שרתי ה-WEB כל אחד בנפרד, לאחר מכן את ה-Cloud services בתוכם הם התארחו, לאחר מכן את שרתי הSQL , את שירות ה-Azure SQL וכו' …
ניהול הרשאות, ניהול ההרשאות מתבצע על כל רכיב בפתרון בנפרד, לא נוכל לאפשר או למנוע גישה ברמת כל הפתרון אלא ברמת כל רכיב ורכיב.
אם ארצה שמשתמש X יכול לגשת לכל השרתים שמרכיבים את הפתרון של אתר האינטרנט שלנו לא נוכל לעשות זאת בצורה מרוכזת אלא נצטרך לאפשר הרשאות בנפרד לכל שרת ושרת, לכל Storage account, לכל Cloud service

חוסר גמישות בפריסה וניהול המשאבים
בהקמת שרת אנו חייבים להכניס אותו תחת Cloud service.
דוגמא נוספת לחוסר גמישות, נניח ויש לנו שלושה שרתים תחת אותו ה-Cloud service ומתחלקת בניהם התעבורה.
החלטנו שאנו מעוניינים שלא תועבר תעבורה לשרת השלישי. האופציה המהירה ביותר היא לכבות את השרת אבל מה יקרה אם אנו מעוניינים שהשרת יישאר דלוק אבל עדיין לא תועבר אליו תעבורה ?
נצטרך להוציא את השרת מה-Cloud service ולשייך אותו ל-Cloud service אחר. לא פעולה פשוטה ומהירה…
ועוד לא דיברנו על מה יקרה אם ארצה להחזיר אותו חזרה ל-Cloud service המקורי.
עוד דוגמא ? יאללה …
הקמתם שרת מבלי לשייך אותו ל-Virtual Network וכעת לאחר שהשרת כבר הוקם עלה הצורך פתאום לשייך אותו ל-Virtual network עליו יושבים שרתים אחרים שלכם על מנת שאותו שרת יוכל לתקשר בקלות עם השרתים שכבר יושבים על אותו Virtual network תוכלו לבצע זאת ? לא …
יהיה צורך למחוק את השרת ולהקים אותו מחדש כדי לשייך אותו ל-Virtual Network.
עוד דוגמא ? יאללה … עוד דוגמא!
בהקמת שרת אין לכם האופציה לבחור אם להקצות כתובת IP חיצונית שדרכה תתאפשר גישה לשרתים או לא. תמיד תוקצה כתובת חיצונית מכיוון שהשרת יושב בתוך Cloud service – לכל  Cloud service מוקצת כתובת חיצונית.

Azure resource manager (ARM) deployment

ניהול מרוכז של המשאבים המרכיבים את ה-"פתרון"/שירות/אפליקציה.
בשיטת הפריסה הזו קיים אובייקט שנקרא Resource group.
ה- Resource group הוא למעשה אובייקט לוגי שנועד לרכז בתוכו כל מיני משאבים שונים הקיימים ב-Azure (שרתים וירטואלים, דיסקים וירטואלים, vNets וכו' …) ולנהל אותם כיחידה אחת.
איזה משאבים לדעתכם נרצה לרכז בתוך Resource group יחיד ?
כל המשאבים של פתרון מסויים, נכון לשייך אותם ל- Resource group ספציפי שיוגדר עבור אותו פתרון.
צורת העבודה הזו מאפשרת לנו ש…

א. נוכל להבין שיש קשר בין כל המשאבים היושבים בתוך ה- Resource group (מרכיבים את תשתית האפליקציה שלנו).
בנקודה הזו עולה לרוב השאלה הבאה ולכן הרשו לי לעצור ולהבהיר לגביה.
האם ניתן לשייך משאבים מ-Deployment regions שונים לאותו Resource group?
והתשובה היא כן, בוודאי! תחשבו שהפתרון שלכם מורכב מאתר ייצור ואתר DR שכל אחד מהאתרים כמובן יושב ב- Deployment regions שונה אבל בפועל הם אותו פתרון … ולכן בהרבה מקרים נרצה לנהל אותם כיחידה אחת.

ב. נוכל לבצע פעולות ניהוליות על הפתרון כיחידה אחת.
לדוגמא, ניהול הרשאות. ברגע שנחיל הרשאה מסויימת ברמת ה- Resource group היא תחול על כל המשאבים תחת אותו ה-Resource group.
דוגמא נוספת, במקרה ונרצה למחוק את הפתרון, ניתן יהיה למחוק את הפתרון בבת אחת, כיחידה אחת בשונה מצורת העבודה ב-classic deployment.

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

גמישות בפריסה וניהול המשאבים
השרתים לא משוייכים יותר ל-Cloud service.
תהיו מעוניינים שיתבצע Load Balancing בין שרתים, אין בעיה … מגדירים אובייקט Load balance מחליטים איזה שרתים משייכים אליו ויבצע Load balance בניהם.
כמובן שבכל שלב תוכלו להוסיף ולהסיר בקלות שרתים ממערך ה-Load balance כרצונכם.
לא רוצים Load balance ? גם זה אפשרי … לא משייכים את השרת לאובייקט Load balance (מה שלא היה אפשרי ב- classic deployment).
בעבודה עם ARM כרטיס הרשת של השרת הוא רכיב עצמאי. העובדה שכרטיס הרשת הוא עצמאי ולא כחלק אינטגרלי מהשרת יאפשר לכם גמישות, תוכלו לשייך שרת וירטואלי לרשת אחרת מבלי למחוק את השרת בשונה ממה שהיה עד כה ב- classic deployment מכיוון שלמעשה אתם מעבירים את כרטיס הרשת לרשת אחרת ולא את השרת.
תוכלו להחליט אם להקצות כתובת IP חיצונית או לא.
יש עוד לא מעט דוגמאות … ברשותכם בשלב זה נסתפק באלה.

ברשותכם, מבט קצר מאחורי הקלעים של התשתית כדי שתכירו את המושג Resource  provider.
ARM עובד במבנה הבא:
המעטפת של כל הפתרון היא ה- resource group.
בתוך ה- resource group ישנה חלוקה של שלושה חלקים הנקראים Resource  providers
Storage Resource provider
Compute Resource provider
Network Resource provider
בתוך כל אחד מה- Resource providers נמצאים המשאבים הסופיים שמרכיבים את הפתרון.
ב- Storage Resource provider נמצאים ה-Storage accounts והדיסקים של השרתים.
ב- Compute Resource provider נמצאים המכונות הוירטואליות.
ב- Network Resource provider נמצאים כל רכיבי הרשת. האובייקטים של ה-LB, האובייקטים של כתובת הIP וכרטיסי הרשת.
ויש קשרי גומלין בין ה- Resource providers,
Storage account שנמצא ב- Storage Resource providerמתקשר עם המכונה הוירטואלית שנמצאת ב- Compute Resource provider ורכיבי הרשת שיושבים בתוך ה- Network Resource providerמקושרים גם הם לשרת הוירטואלי שנמצא ב- Compute Resource provide.

ניקח שוב את הדוגמא של הפתרון שהצגתי כשהסברתי על classic deployment – אתר אינטרנט שמשמש כלוח מכירות יד שניה ונתאר כיצד היא תהיה בנויה ב-ARM.
התשתית מורכבת מ-
– שני שרתי WEB המארחים את ה-Front של האפליקציה, יושבים תחת אובייקט של Load balancer.
– שני שרתי WEB המארחים את המערכת ה-Back office \ CMS של האפליקציה, יושבים תחת אובייקט של Load balancer.
– שני שרתי SQL העובדים בתצורה של SQL mirroring ומארחים את הDB של האפליקציה כל שרת הוא עצמאי/Standalone server
– שירות Azure SQL  (DB as a service) שמארח DB שבו נשמרים הפרטים של המשתמשים שנרשמו ל-Newsletter באתר.
– אובייקט vNet עם מס' Subnets עליהם יושבים השרתים.
וכל האבוייקטים הנ"ל יושבים בתוך Resource group אחד.

רגע נעצור ונדגיש את היתרונות של ARM  על פני השיטה הישנה, היתרונות העיקריים הם:
ניהול מרוכז וגמישות !

ל-ARM יש עוד יתרון בולט לעומת  classic deployment והוא האפשרות לעבוד עם JSON – JavaScript Object Notation.
ניתן לייצא את הגדרות התשתית ל-Template ולפרוס אותו שוב ושוב בקלות רבה וכך לחסוך זמן.

יאמר לזכותם של Amazon Web Service (AWS) שהם עשו זאת מזמן … צורת העבודה הנ"ל והיתרונות שהיא מביאה הייתה נחלתם מאז הציעו את שירותי הענן השיתופי שלהם.
אבל אנחנו סטוקרים של מיקרוסופט ! אז שכחו שאמרתי AWS! והמשיכו להקים את הסביבות שלכם ב-Azure!

Azure resource manager (ARM) deployment זמין כמובן בכל ה-Deployment regions של – Azure והעלויות של השירותים זהות בשתי השיטות.

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

3 תגובות

הוספת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

eighteen + ten =

הרשמו לרשימת התפוצה!