בדף הזה תוכלו לקרוא סקירה כללית על התכונות והפונקציונליות של Google Cloud NetApp Volumes.
אחסון ברשת (NAS)
NetApp Volumes משתף מערכות קבצים, או אמצעי אחסון, עם לקוחות של אחסון ברשת (NAS). לקוחות NAS הם בדרך כלל מכונות וירטואליות (VM) שפועלות במערכות ההפעלה Windows או Linux, באמצעות הפרוטוקולים המקובלים בתחום: מערכת קובצי רשת (NFS) ופרוטוקול SMB.
מודל שרת-לקוח
גם NFS וגם SMB משתמשים במודל של לקוח-שרת, שבו לקוח שולח בקשות לשרת כדי לבצע פעולות במערכת הקבצים. השרת מבצע פעולות כמו יצירה או מחיקה של קבצים או תיקיות, שינוי קבצים, ועיון בקבצים וקריאה שלהם.
מערכות קבצים מוטמעות באמצעי אחסון שאפשר לשתף עם הרבה לקוחות. בדרך כלל, מערכות ההפעלה Windows, Linux ו-UNIX כוללות תוכנת לקוח מובנית של SMB ו-NFS.
הרשאות גישה
לכל האובייקטים במערכת הקבצים חייב להיות בעלים, אבל אתם יכולים לתת למשתמשים ולקבוצות אחרים הרשאות גישה לאובייקטים.
ב-NFS, הבעלות מציינת מזהי משתמשים ומזהי קבוצות, שמשתמשים בהרשאות משתמש וקבוצה רגילות בסגנון UNIX. ב-NFSv4.1 אפשר להשתמש במזהי משתמשים ובמזהי קבוצות או בישויות מורשות. כשמשתמשים ב-NFSv4.1 עם Kerberos, השימוש ב-Kerberos principals מחליף את הגישה באמצעות מזהה משתמש, שמאמת את זהויות המשתמשים. בנוסף להרשאות UNIX רגילות, ב-NFSv4.1 יש גם רשימות של בקרת גישה (ACL) של NFSv4.1 כשיטה חלופית לניהול הגישה.
ב-SMB, מזהי האבטחה של Windows מציינים בעלות ומשתמשים ברשימות של בקרת גישה בסגנון NTFS כדי לנהל את הגישה לאובייקטים.
אחסון בלוקים (block storage)
רמת השירות NetApp Volumes Flex Unified מאפשרת להקצות אחסון בלוקים באמצעות הפרוטוקולים iSCSI ו-NVMe/TCP. באמצעות אחסון בלוקים, אתם יכולים להריץ עומסי עבודה שדורשים גישה ישירה לדיסק, כמו מסדי נתונים, בזמן שהמשתמשים ממשיכים ליהנות מחוויה מנוהלת באופן מלא. השילוב של אחסון בלוקים עם פרוטוקולי iSCSI ו-NVMe/TCP מגדיל את גמישות הפריסה, ומרחיב את מגוון האפליקציות שאפשר לארח ב-Google Cloud.
NetApp Volumes מציג התקני בלוקים למארחים ברשת TCP/IP באמצעות פרוטוקולי iSCSI ו-NVMe/TCP שהם תקנים בתעשייה. פרוטוקול iSCSI מאפשר למכונות וירטואליות שפועלות ב-Windows וב-Linux לגשת ל-NetApp Volumes כדיסקים שמצורפים באופן מקומי, למרות שהאחסון הפיזי הוא מרחוק. אפשר להשתמש ב-NVMe/TCP רק עם שרתי Linux.
מודל מאתחל-יעד
ב-iSCSI נעשה שימוש במודל של יוזם-יעד. הלקוח, שנקרא iSCSI initiator, שולח פקודות SCSI דרך רשתות IP למערכת האחסון, שפועלת בתור iSCSI target. היעד מקבל את הפקודות האלה ומבצע פעולות ברמת הבלוק, כמו קריאה וכתיבה של נתונים, עיצוב דיסקים וניהול מחיצות.
כרכים של NetApp מוצגים כ-LUN (מספר יחידה לוגית) של iSCSI למתחילים כמכשירי בלוק. כל LUN מופיע ללקוח כדיסק גולמי, ומאפשר למערכת ההפעלה ליצור ולנהל מערכות קבצים משלה, כמו NTFS, ext4 או XFS. ברוב מערכות ההפעלה של Windows ו-Linux יש תוכנת iSCSI initiator מובנית, שמפשטת את החיבור ליעדי iSCSI.
ב-NVMe/TCP נעשה שימוש במודל של יעד-יוזם שפועל בתוך מודל הארכיטקטורה הרחב יותר של מארח-תת-מערכת ל-NVMe over Fabrics (NVMe-oF), כדי לגשת לאחסון בלוקים דרך רשתות IP. הלקוח פועל כמארח NVMe ומתקשר עם מערכת האחסון, שחושפת מערכות משנה אחת או יותר של NVMe, באמצעות פרוטוקול NVMe over TCP. מערכת האחסון מציגה את אחסון הבלוקים של NVMe כמרחבי שמות של NVMe ללקוחות Linux.
מידע נוסף על יצירה וניהול של קבוצות מארחים זמין במאמר בנושא קבוצות מארחים.
מאגרי אחסון
מאגרי נפח אחסון מספקים קיבולת לנפחים, ואפשר לחלק את הקיבולת של המאגר בין הנפחים שבו. קיבולת לוגית מתייחסת לקיבולת שאתם מקצים לנפחים ב-Storage Pool, כולל נתוני משתמשים (קבצים ומספרי LUN), תמונות מצב ומטא-נתונים.
כל אמצעי האחסון ב-Storage Pool חולקים את הפרטים הבאים:
מיקום
רמת השירות
רשת של ענן וירטואלי פרטי (VPC)
מדיניות Active Directory
שימוש ב-LDAP לנפחי NFS, אם רלוונטי
מדיניות מפתחות הצפנה בניהול הלקוח (CMEK)
זמינות של מאגרים אזוריים או תחומים
יכולת חלוקה אוטומטית לרמות
מאגרי אחסון מספקים גם יכולות ביצועים לנפחי אחסון:
נפחים במאגרי אחסון לרמות השירות Standard, Premium ו-Extreme מספקים קצב העברת נתונים של 16, 64 ו-128MiBps, בהתאמה, לכל TiB של קיבולת נפח שהוקצתה.
נפחי האחסון במאגרי האחסון של רמת הביצועים שמוגדרת כברירת מחדל בשירות Flex File חולקים את הביצועים של המאגר, שהם 16MiBps לכל TiB של קיבולת המאגר שהוקצתה.
הנפחים במאגרי אחסון ברמות השירות המותאמות אישית של Flex Unified או Flex File חולקים את הביצועים של המאגר. אפשר להגדיר את הביצועים של המאגר בנפרד מהקיבולת.
חיוב
החיוב מתבצע על הקיבולת הלוגית שאתם מקצים למאגר אחסון, ולא על המקום הפיזי בפועל בכונן או על השימוש בנפח ספציפי. החיוב תלוי במיקום המאגר, ברמת השירות ובגודל הכולל שהוקצה, בלי קשר לכמה קיבולת הנפחים צורכים בפועל.
מידע נוסף על חיוב זמין במאמר בנושא תמחור של NetApp Volumes.
אם מפעילים חלוקה אוטומטית לרמות ב-Storage Pool, החיוב תלוי ברמת השירות של ה-Storage Pool. למידע נוסף, קראו את המאמרים הבאים:
מאגרי אחסון מאוחדים ב-Flex עם חלוקה אוטומטית לרמות
במאגרי אחסון מסוג Flex Unified שמופעלת בהם חלוקה אוטומטית לרמות, נתונים בשימוש נדיר מועברים באופן אוטומטי לאחסון בעלות נמוכה יותר. הקיבולת והחיוב של המאגרים האלה תלויים בערכים הבאים:
Hot tier size: הקיבולת שהוקצתה לנתונים פעילים, שמחויבים לפי התעריף של רמת האחסון החמה.
גודל המאגר: הקיבולת הכוללת של המאגר, שכוללת גם את גודל שכבת האחסון החם וגם את השימוש בפועל בשכבת האחסון הקר.
מודל החיוב הזה מאפשר לכם לבצע אופטימיזציה של העלויות בהתאם לעומס העבודה:
אתם מחויבים על גודל השטח המוקצה המלא ברמת התמחור של התוכנית הגמישה.
החיוב מתבצע רק על השימוש בפועל ברמת האחסון הקר.
לא תחויבו על קיבולת שלא נוצלה במאגר.
לדוגמה, נניח שאתם יוצרים מאגר של 12TiB, עם 1TiB שמוקצה לרמה החמה, ועם הזמן אתם כותבים 5TiB של נתונים למאגר. אחרי ש-4.5TiB של נתונים לא פעילים מועברים לרמת האחסון לא פעיל, נשארים 0.5TiB ברמת האחסון הפעיל. בתרחיש הזה, החיוב יהיה כדלקמן:
רמת אחסון פעיל: תחויבו על הקצאה מלאה של 1TiB ברמת האחסון הפעיל לפי התעריף של Flex Unified, גם אם נותרו רק 0.5TiB ברמת האחסון הפעיל.
רמת אחסון קרה: אתם מחויבים על 4.5TiB שמאוחסנים ברמת האחסון הקרה, ועל כל חיוב רלוונטי על פעולות ברשת להעברת הנתונים.
קיבולת לא מנוצלת: לא תחויבו על 6.5 ה-TiB שנותרו בקיבולת המאגר שלא נוצלה.
מאגרי אחסון Premium ו-Extreme עם חלוקה אוטומטית לרמות
במאגרי אחסון Premium ו-Extreme שבהם מופעלת העברה אוטומטית בין רמות אחסון, נתונים בשימוש נדיר מועברים אוטומטית לאחסון בעלות נמוכה יותר. הקיבולת והחיוב של המאגרים האלה תלויים בערכים הבאים:
גודל המאגר: הקיבולת הכוללת שהוקצתה למאגר.
גודל שכבת הנתונים הקרים: הקיבולת שמשמשת את הנתונים באחסון קר.
גודל שכבת האחסון החם: הקיבולת שנותרה במאגר, שמחושבת באופן אוטומטי כגודל המאגר פחות גודל שכבת האחסון הקר. השכבה החמה כוללת נתונים פעילים וגם קיבולת מאגר לא מנוצלת. החיוב הוא על מינימום של 2TiB בנפח האחסון של השכבה החמה בכל מאגר.
החיוב הוא על כל הקיבולת שהוקצתה למאגר בכל אחת מהרמות:
החיוב על גודל שכבת האחסון החמה (נתונים פעילים וקיבולת מאגר שלא נוצלה) הוא לפי התעריף של Premium או Extreme.
החיוב על גודל האחסון ברמת Cold הוא לפי התעריף הנמוך יותר של רמת Cold.
לדוגמה, נניח שיוצרים מאגר של 12TiB וכותבים בו 5TiB של נתונים. אחרי ש-4.5TiB של נתונים בשימוש נדיר מועברים לשכבת הנתונים בשימוש נדיר, 0.5TiB של נתונים פעילים ו-7TiB של קיבולת לא מנוצלת נשארים בשכבת הנתונים בשימוש תכוף. בתרחיש הזה, החיוב מתבצע באופן הבא:
רמת אחסון Hot: החיוב הוא על קיבולת של 7.5TiB ברמת האחסון Hot (מאגר בגודל 12TiB פחות 4.5TiB ברמת האחסון Cold) בתעריף Premium או Extreme.
רמת Cold: החיוב הוא על 4.5TiB שמאוחסנים ברמת Cold, לפי התעריף הנמוך יותר של רמת Cold, בתוספת כל דמי התפעול הרלוונטיים ברשת על העברת הנתונים.
Flex Unified: מצב ברירת מחדל לעומת מצב ONTAP
ברמת השירות Flex Unified יש שתי דרכים להקצות מאגרי אחסון:
מצב ברירת מחדל
מצב ONTAP
אלא אם צוין אחרת, כל המידע במסמך הזה רלוונטי לשני המצבים.
מצב ברירת מחדל
מצב ברירת המחדל מנוהל באופן מלא על ידי Google. כל המשאבים מנוהלים באמצעותGoogle Cloud המסוף, Google Cloud CLI וספק Google Terraform, שכולם פועלים באמצעות Google APIs, בדומה לרמות השירות Standard, Premium ו-Extreme.
הוא מיועד למשתמשים שמעדיפים ניהול פשוט, ואולי אין להם מומחיות רבה באחסון.
השירות מבוסס על Google Cloud NetApp ONTAP, אבל זמינות רק תכונות ONTAP שנחשפות דרך ממשקי Google API. אי אפשר לגשת לתכונות של ONTAP או לשנות אותן אם ממשקי Google API לא תומכים בהן.
מצב ONTAP
מספקת שליטה מתקדמת במערכת ההפעלה של האחסון ב-ONTAP, שמאפשרת להשתמש ברוב התכונות וההגדרות של ONTAP ל-SVM, לנפחים ולפרוטוקולים.
מיועד למשתמשים עם ניסיון בהגדרה ובהפעלה של מערכות אחסון ONTAP.
Google מנהלת רק את Storage Pool, את הרשת ואת ה-CMEK, וכל שאר המשאבים, כמו נפחים, פרוטוקולים וקובצי snapshot, מנוהלים על ידי ממשקי ה-API של ONTAP.
אתם יכולים להשתמש בספק Terraform של Google Cloud כדי לנהל את המאגר, ובספק NetApp ONTAP כדי לנהל את המשאבים שבתוך המאגר. מידע נוסף זמין במאמר שימוש ב-Terraform לניהול מצב ONTAP.
באחריותכם לעקוב אחרי כל המשאבים, למעט Storage Pool, למשל נפחים.
נפחי אחסון
ווליום הוא מאגר של מערכת קבצים ב-Storage Pool שבו מאוחסנים נתונים של אפליקציות, מסדי נתונים ומשתמשים.
אתם יכולים ליצור נפח אחסון באמצעות הקיבולת הזמינה במאגר האחסון, ולהגדיר את הקיבולת ולשנות את הגודל שלה בלי להפריע לתהליכים.
ההגדרות של Storage Pool חלות באופן אוטומטי על אמצעי האחסון שכלולים בו.
תמונות מצב וניהול נתונים שמבוסס על תמונות מצב
בעזרת יכולות התמונות של מצב נתונים ב-NetApp Volumes, אתם יכולים לנהל את השימוש בנתונים. כך אפשר לצלם תמונות מצב של הנתונים תוך שניות בלי לדרוש נפח אחסון נוסף.
תמונות המצב של NetApp Volumes הן לא עותק פיזי נפרד של הנתונים. במקום זאת, קובצי ה-snapshot של NetApp Volumes מתעדים רק את הנתונים שהשתנו מאז ה-snapshot האחרון. שימו לב: כשמחליפים את כל הנתונים, יכול להיות שהתמונות המייצגות יתפסו נפח אחסון משמעותי.
שכפול של אמצעי אחסון
כדי להגן על הנתונים, אתם יכולים להשתמש בשכפול נפח בין מיקומים, שמשכפל באופן אסינכרוני נפח מקור במיקום אחד לנפח יעד במיקום אחר. היכולת הזו מאפשרת לכם להשתמש בנפח האחסון השני לפעילות קריטית של האפליקציה במקרה של הפסקה או אסון בכל המיקום.
במהלך ההעברה הראשונית, שכפול הנפח מעביר רק בלוקי נתונים שהיו בשימוש. במהלך העברות מצטברות עוקבות, רק בלוקים שהשתנו מועברים. החיובים הם רק על בייטים שהועברו, מה שמייעל את זמני ההעברה ומקטין את העלויות.
גיבויים
גיבוי הוא עותק של אמצעי אחסון שמאוחסן בנפרד מאמצעי האחסון בכספת גיבוי. אם אמצעי אחסון לא זמין או נמחק, אפשר להשתמש בגיבויים כדי לשחזר את הנתונים לאמצעי אחסון חדש. ב-NetApp Volumes יש תמיכה בגיבויים ידניים ומתוזמנים של נפחים.
הגיבוי הראשון של אמצעי אחסון מכיל את כל הנתונים של אמצעי האחסון. בגיבויים הבאים נשמרים רק השינויים המצטברים, וכך אפשר לבצע גיבויים מצטברים מהירים לתמיד ולהקטין את הקיבולת הנדרשת בכספת הגיבוי.
שילוב עם Active Directory
פרוטוקולים לשיתוף קבצים כמו SMB (CIFS), NFSv3 עם קבוצות מורחבות ו-NFSv4.1, מסתמכים על שירותי ספריות חיצוניים כדי לספק מידע על זהות המשתמש באמצעות גורמי אבטחה. NetApp Volumes מסתמך על Active Directory לשירותי ספריות. Active Directory מספק שירותים כמו שרתי LDAP לחיפוש האובייקטים הבאים:
משתמשים
קבוצות
חשבונות מכונה
שרתי DNS (לפענוח שם המארח)
שרתי Kerberos (למטרות אימות)
הצפנת הנתונים
ב-NetApp Volumes הנתונים באחסון תמיד מוצפנים באמצעות מפתחות ספציפיים לנפח האחסון.
באמצעות מפתחות הצפנה בניהול הלקוח (CMEK), מפתחות ספציפיים לנפח נארזים באמצעות המפתחות שלכם שמאוחסנים ב-Cloud Key Management Service. התכונה הזו מאפשרת לכם לשלוט יותר במפתחות ההצפנה שבהם אתם משתמשים, ומוסיפה שכבת אבטחה נוספת על ידי אחסון המפתחות במערכת או במיקום שונים מהנתונים. ב-NetApp Volumes יש תמיכה ביכולות של Cloud Key Management Service, כמו מודולים של אבטחת חומרה, ניהול מפתחות הצפנה ומחזור החיים המלא של ניהול המפתחות: יצירה, שימוש, רוטציה והשמדה.
חלוקה אוטומטית לרמות
משתמשים שיש להם כמויות גדולות של נתונים לא פעילים יכולים להפחית את עלות האחסון הכוללת באמצעות חלוקה אוטומטית לרמות. התכונה 'חלוקה אוטומטית לרמות' מעבירה נתונים לא פעילים לרמת אחסון זולה יותר. התהליך הזה שקוף ללקוחות NFS ו-SMB, ולמשתמשים יש גישה מלאה לנתונים. הגישה לנתונים קרים איטית יותר מהגישה לנתונים חמים. מידע נוסף זמין במאמר ניהול החלוקה האוטומטית לרמות.
SnapMirror
SnapMirror מעתיק נתונים מנפח מקור ראשי לנפח יעד משני. היעד יכול להיות באותו אתר או במיקום מרוחק. העותק הזה משמש לגיבוי ולהתאוששות מאסון, כדי לשחזר נתונים אם המערכת הראשית לא זמינה.
SnapMirror תומך ברפליקציה אסינכרונית בין מערכת מקור שמבוססת על ONTAP לבין נפחי יעד של NetApp Volumes. נפחי אחסון במאגרי אחסון מאוחדים של Flex יכולים לשמש גם כנפחי אחסון של מקור. אין תמיכה ב-Synchronous SnapMirror.
אחרי העותק המלא הראשון, SnapMirror מעביר רק נתונים ששונו, מה שמקטין את רוחב הפס ומזרז את העדכונים. הוא גם תומך בתכונות אחסון כמו ביטול כפילויות ודחיסה.
SnapMirror מאפשר להשהות את הרפליקציה באופן זמני כדי לבדוק את תוכנית ההתאוששות מאסון (DR). אחרי אסון, SnapMirror יכול גם להפוך את כיוון השכפול כדי לסנכרן מחדש את המערכות במהירות.
מידע נוסף זמין במאמר SnapMirror בין ONTAP לבין Google Cloud NetApp Volumes.
שיטות נתמכות להעברה ולשכפול
בטבלה הבאה מתוארות שיטות ההעברה והשכפול שתומכות בסוגי נפחים של מקור ויעד.
| עוצמת הקול של המקור | נפח היעד | שיטת השכפול |
|---|---|---|
| כל ONTAP | Standard, Premium, Extreme או Flex Unified במצב ברירת מחדל | העברת נפח או שכפול חיצוני |
| כל ONTAP | מצב Flex Unified ONTAP | SnapMirror |
| מצב Flex Unified ONTAP | Standard, Premium, Extreme או Flex Unified במצב ברירת מחדל | העברת נפח או שכפול חיצוני |
| מצב Flex Unified ONTAP | כל ONTAP | SnapMirror |
| Standard, Premium או Extreme | רגילה, פרימיום או אקסטרים | שכפול נפח |
| מצב ברירת המחדל של Flex Unified | מצב ברירת מחדל מאוחד של Flex | שכפול נפח |
| קובץ Flex | קובץ Flex | רפליקציה של נפח אחסון |
העברת נפח
התכונה העברת נפח מאפשרת להעביר נפחי Flex מבוססי-ONTAP אל NetApp Volumes באמצעות העברה מבוססת-SnapMirror. SnapMirror משתמש בהעברות מצטברות אסינכרוניות ובסיסיות כדי לצמצם את זמן ההשבתה שנדרש במהלך המעבר של עומסי העבודה ל-NetApp Volumes.
התכונה הזו מיועדת להעברות שמוגבלות בזמן. במאמר רפליקציה חיצונית מוסבר איך לבצע רפליקציות שוטפות בין מערכות ONTAP לבין NetApp Volumes.
שכפול חיצוני
שכפול חיצוני מאפשר להגדיר שכפול של נפחי אחסון בין מערכות מקור שמבוססות על ONTAP לבין נפחי אחסון של NetApp באמצעות SnapMirror. SnapMirror משתמש בהעברות מצטברות בסיסיות ואסינכרוניות כדי לשמור על סנכרון בין נפחי האחסון של המקור והיעד. בדומה לשכפול נפח, אפשר להפסיק שכפולים חיצוניים, להמשיך אותם ולהפוך את כיוון השכפול שלהם. הפונקציונליות הזו מאפשרת לכם להשתמש ב-NetApp Volumes כיעדים לתוכנית התאוששות מאסון (DR) במערכות ONTAP מקומיות.
FlexCache
FlexCache היא טכנולוגיה של NetApp שמייעלת את הגישה לנתונים על ידי יצירת עותקים של נפחים במיקומים מרוחקים, שאפשר לכתוב בהם, שהם דלילים וקבועים, וכך הנתונים קרובים יותר למשתמשים. התכונה הזו משפרת את הביצועים של עומסי עבודה שכוללים הרבה פעולות קריאה, על ידי צמצום זמן האחזור והגדלת קצב הנתונים. בנוסף, FlexCache מפשט את ניהול הנתונים בסביבות ענן היברידיות, ומאפשר שמירת נתונים במטמון בענן בלי לדרוש העברה מלאה של הנתונים.
בנוסף, NetApp Volumes מאפשרת ליצור נפחי אחסון של מטמון מנפחי אחסון של מקורות שמתארחים במערכות מקור שמבוססות על ONTAP, כולל נפחי אחסון מאוחדים של Flex במצב ONTAP.
תמיכה בכמה פרוטוקולים של S3 במצב ONTAP
במצב ONTAP, אפשר להגדיר אשכולות כדי לספק גישה ל-S3 לצד פרוטוקולי NAS כמו NFS ו-SMB לאפליקציות שצריכות לגשת לנתונים באמצעות פרוטוקולי S3 ו-NAS. למרות שנפחי קבצים (NAS) ונפחי בלוקים (iSCSI) יכולים להתקיים יחד ב-Storage Pool שמופעל בהם מצב ONTAP, התמיכה בריבוי פרוטוקולים של S3 זמינה רק לנפחי קבצים ב-Storage Pool האלה.
אין תמיכה בקטגוריות S3 עצמאיות. הגישה ל-S3 זמינה רק כחלק מהגדרה של מצב ONTAP שתומכת גם בפרוטוקולים של NAS.
מידע נוסף על ONTAP-mode S3 multiprotocol זמין במאמר ONTAP S3 multiprotocol support.
שילוב של NetApp Volumes עם NetApp Console
NetApp Volumes משולב עם הסוכן של NetApp Console. השילוב הזה נועד לפשט את ניהול האחסון, ומציע פלטפורמה מאוחדת שמפשטת את הטיפול בכל הדרישות של Cloud Storage. מידע נוסף על סוכן NetApp Console זמין במאמר בנושא NetApp Console.