נעים להכיר Microsoft Azure storage service

storage-conceptsהמאמר הפעם נועד לספק היכרות עם Microsoft Azure storage service.
ההסברים יהיו תאורטיים.
נפרט את המאפיינים העיקריים של השירות אותם עליכם להכיר, כדי ליצור הבנה בסיסית אודות אופן העבודה של השירות.
ניגע בנקודות הבאות:
– מה זה Microsoft Azure storage account ?
– נפרט אודות סוגי החשבונות הקיימים בשירות.
– נפרט אודות סוגי ה-Storage הקיימים (Blob, Table, Queue and File)
– נפרט אודות סוגי ה-Blob storage.
– נכתוב אודות יכולת ניהול ההרשאות של החשבון והשירותים שמוגדרים תחתיו.
– נכתוב אודות אפשרויות השרידות שניתן להגדיר לחשבון.
– ניגע בעלויות השירות.
– ניגע במגבלות הקיימות בשירות מבחינת נפחים וכמויות.

שנתחיל ?! כנסו לפוסט!

 

מה זה Microsoft Azure storage account ?
נתחיל דווקא עם תשובה לשאלה מה זה Microsoft Azure storage service?
שירות לאכסון מידע.
איזה מידע ? תמונות, קבצי וידאו, דיסקים של מכונות וירטואליות, קבצי לוג ועוד… נפרט יותר בהמשך.
ומה זה Microsoft Azure storage account ?
השירות עובד באופן כזה שצריך להקים חשבונות Storage בשירות ותחת החשבונות יוצרים כל מיני סוגי Storages (מיד נפרט אודות סוגי ה-Storages).
תחת כל Subscription ניתן להקים עד 100 חשבונות!
כל חשבון יכול להכיל עד 500TB של מידע!

 סוגי חשבונות Storage
ב-Azure קיימים שני סוגי חשבונות Storage
Premium Storage
Standard Storage

לא המקום כאן לפרט במדויק אודות ההבדלים בין סוגי החשבונות, אכתוב על כך מאמר ייעודי שיסקור את ההבדלים בניהם בצורה מדויקת.
אבל בכל זאת, נגיעה קצרה אודות ההבדלים בין סוגי החשבונות.
חשבון Premium הוא חשבון שנוצר על Storages בעלי דיסקים מהירים מסוג SSD ומיועד לצרכי עבודה של עומסים גדולים ואינטנסיביים עם דיסקים. שרתי DB, Exchange וכו'…
נכון לכתיבת שורות אלו Premium Storage לא זמין בכל ה-Azure regions.
בכל רגע נתון תוכלו להתעדכן בקישור הבא Services by region באיזה Regions השירות זמין.
Premium Storage נכון להיום מספק רק אכסון מסוג Blob ורק סוג אחד של Blob – Page blob מיד אסביר מהו Blob storage ומהו Page blob.
המשמעות היא שכיום ניתן להשתמש ב-Premium Storage רק כדי לאכסן דיסקים וירטואליים (VHD files) של שרתים וירטואליים.
חשבון Standard הוא חשבון שנוצר על דיסקים מסוג SAS שהם פחות מהירים מהדיסקים שחשבון Premium מספק.
חשבון Standard זמין כמובן בכל ה-Azure regions.
חשבון Standard מספק אכסון לכל סוגי ה-Storage הקיימים בשירות (Blob, Table, Queue and File) ומיד נפרט אודותיהם.

סוגי ה-Storage הקיימים ב-Azure
אני מניח שכבר הספקתם להבין שתחת כל Storage account (ואני מדבר כרגע על Storage account מסוג Standard) ניתן להגדיר מס' סוגים שונים של Storages.
Blob storage, Table storage, Queue storage ו- File storage.
כל סוג של Storage נועד למטרה שונה.
שימו לב לא להתבלבל בין Storage accounts לבין Storages!
יש סוגים של Storage accounts שהם Premium ו-Standard
ותחת ה- Storage accounts מוגדרים סוגים של Storages שהם Blob storage, Table storage, Queue storage ו- File storage.
ועכשיו, ברשותכם, נפרט קצת אודות סוגי ה-Storages.

Blob storage
מדובר על Storage שנועד לאכסן קבצים.
הקבצים הללו יכולים להיות תמונות, מסמכים, קבצי קול או וידאו, גיבויים, קבצי לוג, דיסק וירטואלי של שרתים וירטואליים (VHD files), קבצי XML וכו' וכו' …
ממש כל סוג של קובץ שאתם יכולים לשמור על המחשב שלכם אתם יכולים לשמור ב-Blob storage.
בדומה למחשב שלכם בו הקבצים מסודרים בתוך ספריות, גם כאן, תחת ה-Blob storage מגדירים Containers ותחתם שומרים את הקבצים.
ה- Containers הן ספריות לכל דבר ועניין רק כינוי שונה.
אין הגבלה לכמות ה-Blob storages שניתן להגדיר תחת ה-Storage account.
אין הגבלה גם על כמות ה-Containers שניתן להגדיר.
המגבלה היחידה היא כפי שציינתי בתחילת המאמר, הקיבולת, עד 500TB לחשבון.
ה-Blob storage מתחלק לשלושה תתי סוגים, סוגים של Blob storage.
כל סוג של Blob storage נועד למטרות שונות.
להלן פירוט של שלושת סוגי ה-Blob storage:
Block blob – נועד להכיל קבצי תמונה, וידאו, קול, מסמכים, דפי אינטרנט כמו HTML, ASPX  וכו' …
כל קובץ בתוך ה-Block blob יכול להיות עד גודל של 200GB וכך גם הגודל הכולל של ה-Block blob, 200GB.
ז"א יכולים להיות מס' קבצים הקטנים מ-200GB בתוך Block blob אחד או קובץ אחד שגודלו 200GB.
Append blob – נועד לקבצים שמבצעים אליהם כתיבה וגדלים בצורה של "טפיחה", ז"א שמתווסף אליהם כל הזמן עוד ועוד מידע לסוף הקובץ.
לדוגמא קובץ לוג, הוא מתחיל כקובץ קטן מבחינת משקל וכל הזמן מתווסף אליו עוד ועוד מידע והגודל שלו גדל.
המידע שמתווסף לקובץ נכנס אליו בצורה מסודרת, מתחיל מהתחלה ומתווסף הלאה לסוף הקובץ לפי סדר. שורה שנכתבה ראשונה לא תיכתב לפניה שורה אחרת.
דוגמא נוספת היא קבצי BAK של SQL Server. כשבמצעים גיבוי ל-DataBase נוצר קובץ BAK שנשמר אליו מידע. לאט לאט הקובץ טופח וטופח תוך כדי תהליך הגיבוי עד שהוא מסיים את תהליך הגיבוי וסוגר את הקובץ.
כל קובץ בתוך ה-Append blob יכול להיות עד גודל של 200GB וכך גם הגודל הכולל של ה- Append blob, 200GB.
ז"א יכולים להיות מס' קבצים הקטנים מ-200GB בתוך Append blob אחד או קובץ אחד שגודלו 200GB.
Page Blob – נועד לאכסן קבצים שיש אליהם פעולות של כתיבה וקריאה באופן רנדומאלי והכתיבות או הקריאות לא מתבצעות בצורה מסודרת מתחילת הקובץ ועוד סופו או רק בסופו אלא בצורה רנדומלית על כל שטח הקובץ.
דוגמא לכך הם קבצי הדיסקים הוירטואליים של השרתים הוירטואליים (VHD files).
כל קובץ בתוך Page blob יכול להיות עד גודל של 1TB וכך גם הגודל הכולל של ה- Page blob, 1TB.
ז"א יכולים להיות מס' קבצים הקטנים מ-1TB בתוך Page blob אחד או קובץ אחד שגודלו 1TB.

עד כאן לגבי סוגי הBlob storage. עכשיו נעבור לסוגים נוספים של Storages.

Table storage
מדובר על Database  NoSQL לכל דבר ועניין.
שואלים את עצמכם מה זה NoSQL ? בקהילת בסיס הנתונים של ישראל מסבירים על הנושא יפה מאוד ובעברית – מה זה NoSQL database ?
בגדול, מדובר על טבלה שמכילה שורות המכונות entity, בתוך כל שורה יש מידע.
תחת ה-Storage account ניתן להקים כמות בלתי מוגבלת של Table Storage כל עוד אתם במסגרת הנפח המקסימאלי ש-Azure מקצים לחשבון (500TB).
תחת כל Table ניתן לכתוב כמות בלתי מוגבלת של entities וגם במקרה הזה, המגבלה היחידה שלכם היא הנפח המקסימאלי של ה-Storage account.
בקישור הבא תוכלו לקרוא יותר אודות ההגבלות Microsoft Azure table storage capacity considerations.

Queue Storage
מעין מחסנית שאפליקציות דוחפות אליה "הודעות" (messages) ואפליקציות אחרות שולפות ממנה את אותן "הודעות".
ה-"הודעות" הללו עליהן אני מדבר הן למעשה הוראות מאפליקציה אחת לשנייה לביצוע פעולה. התור מכיל שלל פעולות מסוימות.
אפליקציה אחת נותנת הוראות לביצוע פעולה ואפליקציה שניה מקבלת את ההוראה דרך המחסנית/תור ומבצעת את אותה ההוראה.
למי מכם שמכיר את ה- Message Queuing service מה-Windows Server זה בדיוק אותו השירות, רק שכאן אתם מקבלים אותו כשירות בענן.
ולא סתם ענן !Azure ינעל העולם! (חחח אתנחתא קצרה לקצת צחוק. מי שלא מבין על מה אני מדבר מוזמן לצפות בווידאו הבא)
לגבי המגבלות, תוכלו להגדיר כמה queues שתרצו תחת כל Storage account.
כל queue יוכל להכיל כמה "הודעות"/messages שתרצו אבל בתנאי שהגודל הכולל של כל ה- queuesלא יעבור את מגבלת הקיבולת של ה-Storage account שלכם.
עוד נקודה חשובה בעניין ההגבלות, כל "הודעה" בתוך התור גודלה יכול להיות עד 64KB.

File Storage
אם אתם קוראים כאן בבלוג, הסיכוי שאתם לא יודעים מה זה Windows share קלוש!
אז… הדרך הקלה ביותר להסביר לכם מה זה File storage היא לשאול, מכירים Share  ב-Windows ?! זה זה!
במקום להגדיר שיתוף על שרת Windows ניתן להגדיר שיתוף ישירות ע"ג שירות ה-Storage של Azure.
בהיבט הנ"ל אין כאן חידוש גדול, מדובר על אפשרות שקיימת גם בעולם ה-Strorage המסורתי.
לא מעט דגמי Storages מסורתיים דוגמת NetApp, EMC  וכו'… מאפשרים גם הם הגדרה של שיתוף ישירות ע"ג ה-Storage.
ה-Share מבוסס על פרוטוקול SMB (היה נקרא CIFS בתקופת ה-NT4, למי שלא נגע בטכנולוגיה המון זמן… ;-)) וכאן ב-Azure התמיכה היא בגרסאות SMB 2.1 ומעלה (הגרסא האחרונה של SMB היא 3.0).
המשמעות היא שניתן להתחבר לשיתוף שמוגדר על ה- File storage ב-Azure רק ממערכות Windows 7\Server 2008 r2 ומעלה.
כיצד עובד ה-File storage?
מגדירים Share, תחתיו מגדירים ספריות ולתוך הספריות מעלים קבצים.
במדריכים בעתיד אסביר Step-by-step כיצד מגדירים Share, כיצד מעלים את הקבצים אליו וכיצד ומתחברים אליו.
כל Storage account יכול להכיל כמות בלתי מוגבלת של שיתופים (Shares) כל עוד החשבון שלכם עומד במגבלות הקיבולת (500TB).
כל אחד ואחד מה- Shares יכול להכיל כמות בלתי מוגבלת של ספריות וקבצים עד למגבלת הגודל הכולל של ה-Share שהיא 5TB.
גודל של כל קובץ בודד בתוך ה-Share יכול להיות עד 1TB.
כמות החיבורים במקביל לכל אחד מה-Shares היא בלתי מוגבלת.

רגע לפני שאחתום את ההסבר לגבי סוגי ה-Storage, מידע שכדאי שתדעו,
כל סוג של Storage מקבל URL ייחודי באמצעותו ניגשים ל-Data.
ה-URL בנוי באופן הבא:
https://accountname.storagetype.core.windows.net

נניח ואנו מדברים כעת על Blob storage שהגדרנו תחת Storage account ששמו jkrstorage,
ה-URL שייווצר עבורו יהיה https://jkrstorage.blob.core.windows.net
כדי לגשת לקובץ ספציפי תחת אותו Storage account עליכם לפנות לנתיב המלא, ז"א, להוסיף את שם ה-Container וה-Blob הרלוונטיים ל-URL.
https://jkrstorage.blob.core.windows.net/containername/blobname
באותו אופן נבנה ה-URL ל-Table storage, Queue storage ו-File storage.
https://jkrstorage.queue.core.windows.net/queuename
https://jkrstorage.table.core.windows.net/tablename
https://jkrstorage.file.core.windows.net/sharename/foldername

שימו לב, ל-File storage ניתן לגשת גם באמצעות גישה לשיתוף
jkrstorage.file.core.windows.net\sharename\\
אסביר על הנושא בעתיד.

דבר נוסף באותו עניין, שם הדומיין ברירת המחדל שמיקרוסופט מקצים עבור ה-Storage accounts (core.windows.net) ניתן להחליף לכל שם דומיין אחר שבבעלותכם.

עד כאן לגבי סוגי ה-Storages. נמשיך …

כעת, ניגע בקצרה בנושא ניהול ההרשאות בשירות ה-Storage.
אני אומר בקצרה מכיוון שיש לא מעט מה להרחיב בנושא ויש צורך להקדיש לו מאמר ייעודי כדי שניתן יהיה להבין אותו לעומק.
אז מה אתם צריכים לדעת בכל זאת כדי להבין את אופן ניהול ההרשאות של השירות בצורה בסיסית ? ככה …
על מנת לגשת ל-Storage account שלנו ולמשאבים שנמצאים תחתיו יש לבצע אימות מול החשבון.
האימות במקרה הזה מתבצע באמצעות " shared access signature" (או בקיצור SAS).
ה-SAS הוא מעין Key\Token שאותו משרשרים ל-URL של כל שירות Storage  אליו רוצים לגשת וכך מתאפשרת הגישה.
דוגמא קטנה שתמחיש את הדברים,
יצרתם שרת וירטואלי ב-Azure ואתם מעוניינים לשייך אליו דיסק וירטואלי (VHD) נוסף על מנת לשמור עליו Data.
אותו ה-VHD  נוצר ע"ג Blob storage.
על מנת שהשרת הווירטואלי יוכל לגשת לקובץ VHD  יש צורך להגדיר בהגדרות השרת את ה-SAS של החשבון עליו מאוכסן קובץ ה-VHD.
כך גם מתבצע האימות עבור Table storage, File storage ו-Queue storage.
לכל Storage account יש שתי SAS.
אם הייתם לידי, הייתי נותן לכם להתחיל לנחש עד שהייתם מגלים בעצמכם, מדוע צריך שתי SAS לכל Storage account ?
אבל אתם לא לידי… ולכן פשוט אענה על השאלה בעצמי.
הסיבה היא כדי לא לגרום להשבתה של שירותים שעושים שימוש ב-Storage account במקרה ומחוללים SAS חדש.
את ה-SAS ניתן להחליף בכל רגע נתון, במידה ונחולל SAS חדש עבור ה-Storage account ונעשה זאת נניח בזמן ששרת וירטואלי ניגש לדיסק שמתארח על אותו Storage account הקשר בניהם יתנתק מהסיבה שבהגדרות השרת מעודכן SAS שונה מזה שמוגדר על ה-Storage account.
בפרק הזמן מהרגע שעדכנתם את הSAS על ה-Storage account ועד שתעדכנו את ה-SAS החדש בהגדרות של השרת הווירטואלי תחוו השבתה.
כדי למנוע השבתה, בסיטואציה שיש לנו שני SAS ל-Storage account זה מאפשר לכם לבצע החלפה של הSAS באופן הבא ולמנוע השבתה.
א. להעתיק את ה-SAS השני (זה שהשרת הווירטואלי לא עושה בו שימוש) ולעדכן אותו בהגדרות השרת הווירטואלי כך שיעשה בו שימוש במקום ה-SAS אותו אנו מתכוונים לחולל מחדש.
ב. לחולל את ה-SAS הישן מחדש.
ג. לעדכן את ה-SAS החדש על המכונה הווירטואלית.
ד. לחולל מחדש את ה-SAS השני.

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

לאחרונה בוצע שיפור בשירות הקשור לנושא ה-SAS וניהול ההרשאות.
אותם שינויים מאפשרים יותר גמישות בניהול ההרשאות.
השיפור מתבטא בעובדה שמעבר ליכולת שהייתה עד לאחרונה לספק SAS שמאפשר לבצע אימות רק ברמת ה-Storage Account עכשיו גם ניתן לחולל SAS שמאפשר גישה רק לסוג ספציפי של Storage או רק למשאבים מסויימים תחת אותו סוג Storage ואפילו מעבר לכך.
תוכלו לנהל את רמת ההרשאה לאותו משאב שאליו אפשרתם את הגישה.
ז"א לקבוע אם אותו SAS יאפשר כתיבה לאותו משאב או אולי רק קריאה או שיאפשר גם לבצע מחיקה או גם וגם וגם.
אותו ה-SAS שמאפשר גישה ל-Storage account מכונה Account SAS ולעומתו ה-SAS שמאפשר גישה ברמת סוג Storage ספציפי או משאב ספציפי מכונה Service SAS.

משהו יוצא דופן בעניין הצורך לבצע אימות מול הStorage.
כאשר מדובר ב-Blob storage קיימת גם האפשרות לאפשר גישה אנונימית ל-Container מסויים, ז"א לגשת לתוכן תחת Container מסויים ללא הצורך באימות.

ועכשיו, נדבר אודות סוגי השרידות שניתן להגדיר לכל Storage Account.
בזמן הגדרת ה-Storage account תתבקשו לקבוע את רמת השרידות לחשבון אותו אתם יוצרים מתוך ארבע אפשרויות.

רמות השרידות של Microsoft Azure storage

 Locally redundant storage (LRS) – המידע בתוך ה-Storage account משוכפל שלוש פעמים בתוך אותה החווה.
כל עותק של ה- Storage account נמצא  ב-Availability set שונה על מנת להבטיח את שרידות וזמינות המידע.
רמת השרידות LRS היא הבסיסית ביותר מבין ארבעת רמות השרידות שה-Azure מספקים והיא מהווה את הגדרת ברירת המחדל.

Zone-redundant storage (ZRS) – המידע בתוך ה-Storage account משוכפל בתוך אותה חווה בפעמיים (כמובן שכל עותק יושב ב- Availability set שונה) ועותק שלישי נשמר בחווה שונה שלרוב תהיה בתוך אותו Region ובמרחק לא רב מהחווה הראשונה. (למי מכם שלא ידע בחלק  מה- Regionsשל Azure יש יותר מחווה/מתקן אחד ).
רמת השרידות הזו זמינה בשלב זה רק עבור Storage מסוג Block blob.

Geo-redundant storage (GRS) – ברמת השרידות הזו המידע בתוך ה-Storage account משוכפל שלוש פעמים בתוך אותה חווה כשכל עותק נמצא ב-Availability set שונה.
בנוסף, המידע גם משוכפל לחווה נוספת ב-Region התאום של ה-Region בו הגדרנו את הStorage account וגם שם ב- Region התאום המידע משוכפל שלוש פעמים כשכל עותק נמצא ב-Availability set שונה. ז"א יש שישה עותקים של המידע!
תוכלו לחזור קצת אחורה בפוסטים ולקרוא אודות ה- Regions ומה זה Region" תאום" (תאום מלשון תאומים) – Windows Azure
Data Centers

Read-access geo-redundant storage (RA-GRS) – רמת השרידות הזו זהה לחלוטין ל- Geo-redundant storage (GRS)בתצורתה ההבדל הוא שברמה זו המידע שנמצא ב- Region התאום ניתן רק לקרוא ממנו ולא לכתוב אליו.

מחירים של שירות Microsoft Azure Storage

מיותר לציין את המחיר המדויק של השירות מכיוון שיש עדכונים בתג המחיר מדי פעם,
אך מדובר על עלות נמוכה מאוד.
תוכלו להתעדכן במחירים המדוייקים של השירות בקישור הבא – Azure Storage Pricing
מה שכן חשוב לציין ולדבר עליו בעניין המחיר הוא איזה גורמים משפיעים על מחיר השירות.
– התשלום הוא לפי GB שאתם צורכים בפועל וישנם כמה רמות מחיר ל1TB הראשונים תג מחיר מסויים, מ49TB ומעלה תג ומחיר אחר וכן האלה, ישנם כמה רמות.
– כמות הקריאות והכתיבות שבוצעו מול החשבון.
– סוג חשבון ה-Storage (Premium\Standard)
– סוג ה-Storage (Blob, files,queue,table)
– ה-Region בו מוגדר ה-Storage account
– רמת השרידות שמוגדרת לחשבון.

זהו… עד לפוסט הבא.
תגובות, הארות/הערות, בקשות או שאלות, בתחתית הפוסט.

הוספת תגובה

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

fourteen − 11 =

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