אודות סביבות מקוונות או דיירים מרובים

יישומי Customer Engagement ‏(Dynamics 365 Sales, ‏Dynamics 365 Customer Service, Dynamics 365 Field Service‏, Dynamics 365 Marketing, ו- Dynamics 365 Project Service Automation), מעניקים לך אפשרויות לבודד את הנתונים שלך ואת גישת המשתמש. עבור מרבית החברות, הוספה ושימוש בסביבות מרובות במנוי שלך מספקים את השילוב הנכון של פונקציונליות ונוחות ניהול. לארגונים עם מיקומים גיאוגרפיים נפרדים מומלץ לשקול שימוש בדיירים מרובים כדי להפריד בין רשיונות. סביבות מרובות יכולות לשתף משתמשים בין סביבות; דיירים מרובים לא יכולים לעשות זאת.

שימושים של סביבות מרובות

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

סביבות מרובות כיחידות בבניין.

דרושות סביבות מרובות כאשר יש צורך בבידוד של יישומי plug-in, זרימות עבודה או משאבי הניהול שקשה לבודד אותם בקלות באמצעות יחידות עסקיות.

פריסה מרובת סביבות

פריסה רגילה כוללת דייר אחד בלבד. דייר יכול לכלול סביבה אחת או יותר; עם זאת, סביבה תמיד משויכת לדייר יחיד.

פריסת דייר יחיד.

דוגמה זו משתמשת בשתי סביבות עבור שלושה צוותים: מכירות, שיווק ושירותים.

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

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

אודות דייר יחיד עם סביבות מרובות:

  • כל סביבה בתוך דייר מקבלת מסד נתונים משלה של SQL.

  • נתונים לא משותפים בין סביבות.

  • ראה ב- נפח אחסון ב- Microsoft Dataverse איך משתפים אחסון בין סביבות.

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

  • באפשרותך להגדיר קבוצות אבטחה נפרדות עבור כל הסביבות.

  • משתמש מורשה יכול לגשת לכל הסביבות המשויכות לדיירים. השליטה בגישה היא על-ידי חברות בקבוצת אבטחה של סביבה.

  • באפשרותך לרכוש סביבות נוספות באמצעות ההרחבה 'סביבה נוספת'. ניתן להוסיף סביבות נוספות רק למנויים "בתשלום" - לא לגירסת ניסיון ולא לזכויות שימוש פנימי (IUR). אם רכשת את המנוי שלך באמצעות רישוי רב משתמשים, עליך לעבור דרך משווק תיק הלקוח הגדול שלך (LAR) כדי לרכוש את הסביבה הנוספת. מידע נוסף: מבט כולל על תמיכה

  • אין אפשרות למזג גירסאות ניסוי קיימות או מנויים אל סביבה נוספת; במקום זאת, יהיה עליך להעביר את ההתאמות האישיות והנתונים שלך.

מדוע להשתמש בסביבות מרובות?

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

ניהול נתונים ראשיים

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

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

אבטחה ופרטיות

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

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

מדרגיות

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

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

הוספת סביבה למנוי שלך

לקבלת מידע על אופן ההוספה של הסביבה למנוי שלך, ראה יצירה וניהול של סביבות.

פריסה מרובת דיירים

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

פריסה מרובת דיירים.

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

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

אודות דיירים מרובים:

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

    לדוגמה, אם למשתמש א' יש חשבון גישה לדייר A, הרשיון שלו מאפשר לו לגשת לכל הסביבות שנוצרו בתוך דייר A - אם הן מורשות על-ידי מנהל המערכת שלהן. אם משתמש א' צריך גישה לסביבות בתוך דייר B, הוא יזדקק לרשיון נוסף.

  • כל דייר דורש מנהל(י) Microsoft Power Platform עם אישורי כניסה ייחודיים, וכל סניף דיירים ינהל את הדיירים שלו בנפרד במסוף המנהל.

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

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

  • אין אפשרות ליצור פדרציה מקומית של Active Directory עם יותר מדייר אחד אלא אם כן יש לך תחומים ברמה העליונה שעליך לאחד עם דיירים שונים (לדוגמה Contoso.com ו-Fabricam.com).

מדוע להשתמש בדיירים מרובים?

הסבה פונקציונלית

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

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

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

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

  • לכידת מידע. לדוגמה, לכידת המיקוד בארצות הברית תתאים ללכידת קוד ה-Post בבריטניה.

  • טפסים, זרימות עבודה.

הפצה פיזית

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

הוסף פריסה מרובת דיירים לרישוי רב משתמשים

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

אילוצים של ריבוי לקוחות

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

  • אין אפשרות לשתף חשבונות משתמשים, זהויות, קבוצות אבטחה, מנויים, רשיונות ואחסון בין דיירים.

  • אפשר לאחד תחום יחיד רק עם לקוח אחד.

  • כל לקוח חייב להיות בעל שמות משלו; אין אפשרות לשתף את טווחי השמות UPN או SMTP על-פני לקוחות.

  • אם קיים ארגון שמשתמש בגירסה המקומית של Exchange, אין באפשרותך לפצל ארגון זה על-פני מספר לקוחות.

  • רשימת כתובות כללית מאוחדת לא תתפרסם, אלא אם היא מנוהלת במפורש במורד הסינכרון.

  • שיתוף פעולה בין-לקוחות יהיה מוגבל לאיחוד של Lync ומאפייני האיחוד של Exchange.

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

  • לא יכולים להיות חשבונות כפולים בין הלקוחות או מחיצות בגירסה המקומית של Active Directory.

למידע נוסף

בלוג: מהו דייר?
מבט כולל על סביבות