همه چیز درباره VMware Virtual SAN – قسمت سوم (پایانی)

VMware Virtual SAN یا به اختصار vSAN، یک راهکار ذخیره‌سازی نرم‌افزارمحور یا به عبارتی Software-Defined Storage برای زیرساخت های Hyper-Converged محسوب می‌گردد که دنیای ذخیره‌سازهای مجازی را متحول نموده است و هدف ما در این سری مقالات معرفی بیشتر این محصول می‌باشد. در قسمت‌های اول و دوم این مجموعه ضمن مرور کلی، به تشریح ویژگی‌های گسترده‌ی این تکنولوژی پرداختیم و در این مقاله که قسمت سوم و پایانی این سری مقالات است، به بررسی وضعیت‌های مختلف، برخی مزایا و محدودیت‌ها و همچنین مقایسه میان آن و Storageهای قدیمی می‌پردازیم.

وضعیت انطباق‌پذیری ماشین مجازی: سازگاری و ناسازگاری

زمانی یک ماشین مجازی در vSAN، ناسازگار یا Noncompliant محسوب می‌شود که یک یا تعدادی از Objectهای آن قادر به برآورده نمودن الزامات Storage Policy معین شده برای آن نباشد. برای مثال ممکن است هنگامی که نسخه‌های پشتیبان VM غیرقابل دسترس باشند، وضعیت آن ماشین به عنوان ناسازگار محسوب گردد. اگر ماشین‌های مجازی در مطابقت با الزامات تعریف شده‌ در Storage Policy باشد، آن VM در وضعیت Compliant یا سازگار خواهد بود. از قسمت Physical Disk Placement در صفحه‌ی Virtual Disks می‌توان وضعیت انطباق  Object ماشین مجازی را تایید نمود.

وضعیت‌های Degraded و Absent در vSAN

vSAN وضعیت‌های خرابی اجزا را به صورت زیر معین نموده است:

• Degraded: زمانی یکی از اجزا Degraded محسوب می‌شود که vSAN بُروز خرابی در یکی از اجزا اصلی را تشخیص داده و تعیین نماید که این Component خراب دیگر نتواند به حالت اصلی خود باز گردد. در نتیجه vSAN بلافاصله اقدام به بازسازی آن جز خراب می‌پردازد.
• Absent: زمانی یکی از اجزا Absent محسوب می‌شود که vSAN بروز یک مشکل موقتی در اجزا و اطلاعات موجود در آن‌ها را تشخیص دهد، این خرابی امکانِ اصلاح و بازگشت به حالت اولیه را دارا می‌باشد. این حالت ممکن است در هنگام راه‌اندازی مجدد Hostها و یا جدا نمودن یکی از تجهیزات از vSAN Host رخ دهد. vSAN پس از حدود 60 دقیقه شروع به بازسازی اجزا در حالت Absent می‌نماید.

وضعیت Object: صحت و عدم‌صحت عملکرد

یک Object بسته به نوع و تعداد خرابی‌ها در کلاستر، ممکن است در وضعیت‌های زیر باشد:

• Healthy: هنگامی که حداقل یک کپی کامل و یا کمترین تعداد مورد نیاز از بخش‌های اطلاعاتی موجود باشد، آن Object در وضعیت صحت در نظر گرفته می‌شود.
• Unhealthy: یک Objectهنگامی در وضعیت عدم‌صحت می‌باشد که هیچ کپی کاملی در دسترس نباشد و یا کمترین تعداد مورد نیاز از بخش‌های اطلاعاتی برای Objectهای RAID 5 یا RAID 6 موجود نباشد. در صورتی که کمتر از 50 درصد از Voteهای یک Object موجود باشد، آن Object در وضعیت عدم‌صحت قرار دارد. چندین خرابی در کلاستر می‌تواند منجر به وضعیت عدم‌صحت Object شود. هنگامی که یک Object در وضعیت عملکردی Unhealthy قرار دارد، این وضعیت بر در دسترس بودن VM مربوط به آن تاثیرگذار خواهد بود.

Witness چیست؟

Witness یکی از اجزایی است که تنها حاوی Metadata بوده و هیچ اطلاعات برنامه‌های کاربردی واقعی را شامل نمی‌شود. پس از یک خرابی احتمالی و هنگام‌ اتخاذ یک تصمیم، با در نظر گرفتن دسترس‌پذیری اجزای پایگاه داده باقی مانده، این جزء مشابه یک Tiebreaker عمل می‌نماید. Witness هنگام استفاده از On-Disk Format 1.0، برای Metadata بر روی vSAN Datastore تقریبا 2 مگابایت فضا اشغال می‌نماید و این فضای مصرفی هنگام استفاده از On-Disk Format برای نسخه 2.0 و نسخه‌های قبل از آن 4 مگابایت می‌باشد.

نسخه‌ی 6.0 vSAN  و نسخه‌های بعد از آن با استفاده از یک سیستم Asymmetrical Voting یا به عبارتی رای گیری نامتقارن، یک Quorum را حفظ می‌نماید که در واقع هر یک از اجزا باید دارای بیش از یک رای، برای تعیین دسترس‌پذیری Objectها باشند. برای اینکه یک Object در دسترس محسوب شود، باید بیش از 50 درصد آرا که Storage Object یک ماشین مجازی را تشکیل می‌دهند، همیشه برای آن Object در دسترس باشند. هنگامی که 50 درصد رای‌ها و یا کمتر در دسترس تمامی Hostها باشد، آن Object دیگر برای vSAN Datastore موجود محسوب نمی‌شود. عدم وجود یا غیر قابل دسترس بودن یک Object بر دسترس‌پذیری VM مربوط به آن تاثیرگذار می‌باشد.

(Storage Policy-Based Management (SPBM

هنگام استفاده از vSAN، می‌توان الزامات Storage ماشین مجازی، از جمله عملکرد و دسترس‌پذیری را در غالب Policy تعیین نمود. vSAN تضمین می‌نماید که حداقل یک Storage Policy بر VMهای پیاده‌سازی شده بر روی Datastoreها اختصاص یافته باشد. هنگامی‌که الزامات Storage ماشین مجازی شناخته شد، می‌توان PolicyهایStorage  را تعیین نموده و آن‌ها را به VMها اختصاص داد. در صورتی که هنگام پیاده‌سازی ماشین‌های مجازی، Policy ذخیره‌سازی بر آن اعمال نشود، vSAN به صورت خودکار و با استفاده از موارد زیر یک Policy پیش‌فرض به VMها اختصاص می‌دهد:

• Primary Level Of Failures To Tolerate یا به اختصار PFTT پیکربندی‌شده به یک Object، که یک نوار دیسک واحد برای هر Object می‌باشد
• Thin Provisioned Virtual Disk

 لازم به ذکر است که حتی اگر الزامات Policyهای تخصیص داده شده، همانند Policyهای ذخیره‌سازی پیش‌فرض باشد، به منظور دست‌یابی به بهترین نتایج، باید Policyهای ذخیره‌ساز ماشین مجازی را تعیین نمود.

Ruby vSphere Console

Ruby vSphere Console یا به اختصار RVC به منظور مدیریت و عیب‌یابی کلاستر vSAN، یک رابط خط فرمان فراهم می‌نماید. RVC به جای دید متمرکزی از Host]ا که Esxcli ارائه می‌داد، دیدی وسیعی از کلاستر فراهم می‌نماید. این کنسول با هر دو vCenter Server برنامه و ویندوز همراه می‌باشد بنابراین نیازی به نصب جداگانه‌ی آن‌ها نمی‌باشد.

vSphere PowerCLI

vSAN با استفاده از VMware vSphere PowerCLI قادر به پشتیبانی از Scripting خط فرمان می‌باشد و بدین وسیله کاربر قادر خواهد بود تا عملیات مدیریت و پیکربندی را خودکارسازی نماید. PowerCLI که حاوی دستوراتی برای تنظیم اجزا vSAN می‌باشد، برای vSphere API یک رابط Windows PowerShell فراهم می‌کند.

vSAN Observer

VMware vSAN Observer یک ابزار مبتنی بر وب بوده که بر روی RVC به اجرا در آمده و به منظور تجزیه و تحلیل عملکرد عمیق و همچنین مانیتورینگ کلاستر vSAN مورد استفاده قرار می‌گیرد. از vSAN Observer به منظور مشاهده آمار عملکرد لایه ظرفیت، اطلاعات آماری در مورد گروه‌های دیسک فیزیکی، بار فعلی موجود بر روی CPU، مصرف Poolهای حافظه‌ی vSAN و توزیع Object به صورت فیزیکی یا In-Memory در سرتاسر کلاسترهای vSAN استفاده می‌گردد.