قابلیت Fault Domains در vSAN را می‌توان به اختیار پیکربندی کرد تا قابلیت خودترمیمی یک کلاستر طبق توپولوژی کاربر بهبود یابد. با این کار می‌توان اطمینان حاصل نمود که طی رویدادی که یک هاست یا گروهی از آن‌ها، مانند Rack دسترس‌پذیر نیستند، داده کلاستر در دسترس بماند. همان طور که در شکل فوق نشان داده شده است، vSAN با مرتبط‌‌سازی منطقی گروهی از هاست‌ها در vSAN Cluster، محل قرار گرفتن داده‌ها را تعیین می‌کند تا لایه‌های خودترمیمی مطابق با Storage Policy تجویزشده برای یک Object خاص، مانند VMDK، حفظ شود.
قابلیت Fault Domains در vSAN هدفی قابل فهم می‌باشد که پیکربندی ساده‌ای دارد، اما نکاتی را در خصوص طراحی و عملکرد آن باید در نظر گرفت که هرازگاهی نادیده گرفته می‌شود.
تعداد Fault Domains توصیه‌شده در vSAN Cluster
تعداد Fault Domains مورد نیاز را باید از طریق پاسخ به پرسش دیگری به دست آورد: چه سطحی از عدم تحمل (Failure To Tolerate یا به اختصار FTT) در استفاده از این کلاستر مورد نظر است؟ اگر قرار است حداکثر از FTT=1 از طریق RAID-1 Mirroring استفاده شود، در این صورت حداقل به 3 Fault Domains نیاز خواهد بود، و نیز اگر Objectهایی وجود دارند که مستلزم FTT=2 با استفاده از RAID-6 هستند، حداقل به 6 Fault Domains نیاز خواهد بود.
به کمک این اطلاعات می‌توان کمترین تعداد Fault Domain را برای به اجرا درآوردن یک Storage Policy خاص تعریف کرد، اما این تعداد دامین توصیه نشده است. پیشنهاد می‌شود که حداقل از استراتژی N+1 استفاده گردد، درست همان تعداد هاست که در کلاسترهای vSAN بدون Fault Domains نیاز می باشد. این یعنی، همان طور که درشکل 2 نشان داده شده، یک دامین بیشتر از حداقل دامین مورد نیاز در نظر گرفته شود. این کار vSAN را قادر می‌سازد تا در صورت خرابی کامل Fault Domains، خود را به طور خودکار بهبود بخشد تا بتواند یک Fault Domain دسترس‌پذیر دیگر را به جای دامین قبلی بازسازی کرده و به این ترتیب سطح انعطاف‌پذیری تعریف‌شده توسط Storage Policy را دوباره به دست آورد.
تعداد هاست پیشنهادشده در Fault Domains
انتخاب این تعداد، منابع آزاد در دسترس برای بازسازی داده را در صورت خرابی صرفا یک هاست در Fault Domain (برخلاف خرابی کامل Fault Domain) مشخص می‌کند و Fault Domain دیگری وجود نخواهد داشت تا به منظور بازسازی مورد استفاده قرار بگیرد. می‌توان به ازای هر Fault Domain تنها یک هاست را مورد استفاده قرار داد، اما این کار مانع از رسیدن این قابلیت به هدف خود می‌شود. همچنین می‌توان دو هاست را وارد عمل کرد، اما در این صورت نیز ممکن است این هاست‌ها در رویداد خرابی یک هاست در Fault Domain، نتوانند ظرفیت کافی فراهم کنند. قرار دادن سه هاست در Fault Domain آغاز واقع‌بینانه‌ای است، چرا که هرگاه یک هاست قطع شود و Fault Domain دیگری در دسترس نباشد تا انطباق یک Object با Storage Policy را بازیابی کند، این نوع پیکربندی کمتر دچار مشکل می‌گردد. هر چه تعداد Fault Domainها (بیش از حداقل مورد نیاز) افزایش یابد، از اهمیت تعداد هاست‌های درون آن کاسته می‌شود.
اهمیت تقارن در قابلیت Fault Domain در vSAN
vSAN نیازی ندارد که هاست‌های کلاستر دقیقا متقارن باشند. برابرسازی سطح منابع در هر هاست، روشی مناسب برای کلاسترینگ است، خواه CPU باشد، خواه حافظه و یا منابع Storage در vSAN. تقارن هاست‌ها، اطمینان از در دسترس بودن منابع کافی را در حین وقوع هرگونه خرابی، بسیار ساده‌تر می‌کند. این امر به ویژه در خصوص کلاسترهایی که تعداد بسیار کمی هاست دارند، صحت دارد. همان طور که در شکل 3 نشان داده شده است، خرابی هاستی که تعداد بسیار زیادی از منابع را فراهم می‌کند و در جاهای دیگر منابع کافی نباشد، مسئله‌ساز خواهد بود.
توصیه مبنی بر تقارن هاست‌ها، به ویژه برای vSAN Clusterهایی که تعداد بسیار کمی هاست دارند، به همان دلیلی است که تقارن در سراسر Fault Domains پیشنهاد گردیده است. در این مورد، تقارن باید برای خصوصیات هاست و تعداد هاست به ازای هر Fault Domain حفظ شود. نامتقارن بودن منابع درFault Domains مانند عدم تقارن در یک کلاستر بسیار کوچک است. در صورت وقوع خرابی ممکن است به موجب این عدم تقارن، جایگذاری داده به سختی انجام شود.
استفاده از Fault Domaint و وتاثیر آن بر Free Space
منظور از فضای آزاد معمولا درصد ظرفیت دسترسی‌پذیر در سراسر کلاستر است. vSAN فضای آزاد را در سطوح بسیار متمایزتری می‌بیند: هاست‌ها، دیسک گروه‌ها و حتی هر یک از دیسک‌ها. Fault Domain جایگذاری و محدودیت فضای آزاد دیگری را برای vSAN معرفی می‌کند. در صورت بروز هرگونه خرابی (چه در آن Fault Domain دخیل باشد و چه نباشد)، vSAN به دنبال مکانی است که داده‌ها را اصلاح کند، به طوری که با رونوشت دیگر داده‌ها همپوشانی نداشته باشد. همچنان توصیه می‌شود کلاسترهایی که از Fault Domains استفاده می‌کنند، 25 تا 30 درصد از ظرفیت را برای این اقدامات زودگذر آزاد نگه دارند.
در صورت استفاده از فرآیندهای حذف داده‌های تکراری (Deduplication) و فشرده‌سازی، همین ملاحظات در خصوص کلاسترهایی که از Fault Domains استفاده می‌کنند نیز صدق می‌کند، درست مانند کلاسترهایی که این دامین‌ها را به اجرا درنمی‌آورند. این قابلیت فرصت مناسبی را برای کارآمد ساختن فضا فراهم می‌کند. انتقال داده، که طی اقداماتی چون تغییرات Storage Policy و خرابی هاست صورت می‌گیرد، بدین معنی است که هیچ تضمینی نیست که سطح موثری از ظرفیت به ذخیره‌سازی اختصاص داده شود.
قابلیت Fault Domains در مقایسه با استفاده از چندین کلاستر
منظور از پیش‌نیازهای Fault Domains این است که آن‌ها معمولا در کلاسترهایی فعال می‌شوند که دارای تعداد متوسط تا زیادی هاست هستند. اگر سازمانی خواهان استفاده از قابلیت Fault Domain باشد و نیز طرحی در نظر داشته باشد (تعداد Fault Domain ضربدر تعداد هاست‌های هرکدام)، پس باید به دنبال آن سوال مناسبی مطرح شود: آیا با استفاده از چندین vSAN Cluster به جای Fault Domains، نتیجه‌ی دلخواه حاصل می‌شود؟ و آیا نیازها بهتر برآورده می‌شوند؟
کاربرد vSAN در Disaster Recovery
ویدیوهای بیشتر درباره vSAN
در سناریویی که در شکل زیر نشان داده شده، باید با استفاده از چندین کلاستر به جای قابلیت Fault Domains، حفاظت در سطح Rack به عمل آید. در این حالت یک کلاستر به ازای هر Rack فقط شامل یک هاست خواهد بود، بدین ترتیب یک Fault Domain ضمنی (به عمق یک هاست) ایجاد می‌کند.
در این حالت قطعا قابلیت‌های جالب انعطاف‌پذیری که درvSAN Fault Domain یافت می‌شد، فراهم نمی‌شود، چرا که به ازای هر Rack در یک کلاستر فقط یک هاست می‌توان داشت. استفاده از چندین کلاستر قابلیت منحصربه‌فرد دیگری نیز دارد: دارای یک دامین کوچکتر عملیاتی و نگهداری هستند. سرویس‌های کلاستر (حذف داده‌های تکراری، فشرده‌سازی، رمزگذاری و …) را می‌توان برای مجموعه‌ی کوچکتری از هاست‌ها تنظیم کرد و این کار مدیریت نگهداری و رویدادهای ناخواسته را آسان‌تر می‌کند.
