مقایسه معماری VVOLs با معماری سنتی ذخیره سازی

مقایسه معماری VVOLs با معماری سنتی ذخیره سازی

Datastore در معماری سنتی‌ vSphere و مجازی‌سازیِ Storage برای ماشین‌‌های مجازی دو هدف را دنبال می‌کند، اول اینکه یک Endpoint برای دریافت دستورات خواندنی و نوشتنی NFS و SCSI باشد و دوم اینکه یک Storage Container برای تعدادی از Metadata و فایل‌های داده‌ در ماشین مجازی باشد.

Protocol Endpoint در معماری Virtual Volumes به عنوان یک مکانیسم انتقال برای شبکه عمل نموده و Storage Container که به صورت منطقی تعریف شده است، به عنوان یک Datastore مجازی عمل می‌کند. Policy پیش‌فرض Storage را می‌توان به Storage Container اعمال نمود و به هریک از ماشین‌های مجازی واقع در آن نیز انتقال داد.

همچنین ضرورتی وجود ندارد که ماشین‌های مجازیِ موجود در یک Storage Container مجموعه‌ای از ویژگی‌های کلی تعریف شده برای Storage Container را به اشتراک بگذارند، بلکه هر ماشین مجازی می‌تواند دارای یک Policy جداگانه باشد که ممکن است در تمامی Containerهای Storage یکسان باشد. از آنجایی که این ماشین‌های مجازی به صورت منطقی تعریف شده‌ و به یک LUN استاتیک یا گروهی از دیسک‌ها مرتبط نمی‌باشند، از این قابلیت برخوردارند که در هر مکان یک نمونه‌ از ماشین مجازی را همراه با Container به نمایش بگذارند که همسو با Policy مرتبط با آن باشد.

Storage Container ممکن است شامل قسمت‌هایی از Storage با پیکربندی‌های مختلف‌‌ RAID، پیکربندی‌های متفاوت در عملکرد و مواردی دیگر باشد و ماشین مجازی را در یک موقعیت مناسب پیاده‌سازی کند. علاوه بر این موارد، چندین سرویسِ داده و انواع مختلفی از قابلیت‌ها می‌توانند در Storage Containerهای تعریف شده به صورت منطقی ارائه شوند.

در نتیجه‌ این امکان برای ماشین‌‌های مجازی فراهم می‌گردد تا Policyهای مختص به خود را برایStorage  داشته باشند و در عین حال همراه با دیگر ماشین‌‌های مجازی به صورت مناسب در Container جای داده شوند. هریک از این ماشین‌‌ها از Policy مختص خود برخوردار بوده که لزوما با Policy مربوط به همه‌ی VMDKهای ذخیره شده در Container مشترک نمی‌باشد.

با ذخیره تعداد زیادی ماشین مجازی در یک NFS Mount-Point یا LUN واحد که توسط یک Storage Container در دسترس قرار می‌گیرد، تعداد Entity‌ها در ساختار، پیکربندی آنها و سربار مقیاس‌پذیری کاهش می‌یابد اما قابلیت Granularity محدود می‌گردد؛ با کمک این قابلیت می‌توان سرویس‌های داده را بین Host‌ها و Storage اصلی استفاده نمود.

در یک مدلِ استاندارد و عملیاتی برای ذخیره‌سازی می‌توان تعداد زیادی ماشین مجازی را بر روی یک Datastore واحد پیاده‌سازی نمود و در نتیجه از تعداد Entity‌ها در LUN یا NFS در ساختار ذخیره‌ساز کاسته و سربار مقیاس‌پذیری و پیکربندی را به حداقل رساند.

با این رویکرد، قابلیت Granularity که با آن سرویس‌های داده قابل ارائه به ماشین‌های مجازی می‌باشند، محدود شده و پروفایل‌های بسیار مشابه در تمامی برنامه‌های کاربردی به منظور دستیابی به موفقیت ضرورت می‌یابد.

این تکنولوژی در یک محیط با سیستم ذخیره‌سازی مبتنی بر نرم‌افزار (SDS) با Virtual Volumes، به ارائه یک Protocol Endpoint می‌پردازد که یک Entity قابل شناسایی در ساختار فیزیکی محسوب می‌گردد. برای مثال، سیستم‌های ذخیره‌ساز SAN می توانند یک Proxy LUN Protocol Endpoint را ارائه نمایند که با استفاده از دستورات معمول برای شناسایی LUN شناسایی می‌گردند.

Protocol Endpoint از طریق چندین مسیر قابل دسترسی می‌باشد که ترافیک در این مسیرها مطابق با Policyهای انتخاب مسیر جریان می‌یابد. Policyهای انتخاب مسیرِ VMware شامل موارد زیر می‌باشد:

• بیشترین مسیر استفاده شده
• Round Robin
• مسیر ثابت

بررسی ویژگی‌های SAN و NASهای غیر VVol

• VMFS

فایل سیستم کلاستر شده که برای فرمت کردن LUN به کار می‌رود.

• (vSphere API for Storage Awareness (VASA

قابلیت‌‌های Storage به صورت پروفایل‌های Read-Only مرتبط با Datastore‌ها در دسترس لایه مجازی‌سازی قرار می‌گیرند که این قابلیت در حال حاضر از طریق ویژگی ‌Profile-Driven Storage در vSphere در دسترس می‌باشد. در این فرآیند پیاده‌سازی، پروفایل‌ها به عنوان Tag برای دیسک‌‌های مجازی و Datastore‌ جهت تسهیل روند آماده‌سازیِ به کار می‌روند؛ ضمن اینکه برای کنترل فرآیند نصب سرویس‌های داده مجزا مورد استفاده قرار نمی‌گیرند؛ برای مثال چنانچه Replication در LUN فعال باشد، این قابلیت از طریق Policy مربوط به ماشین مجازی قابل اصلاح نمی‌باشد.

• (vSphere API for Array Integration (VAAI

مجموعه‌ای محدود از Block، NAS و Primitiveهای Thin Provisioning

• Profile-Driven Storage در vSphere

قابلیت Tag نمودن دیسک‌های مجازی مبتنی بر پروفایل‌‌های استاتیک Read-Only

• Storage DRS

قابل اجرا در سطح Volume و LUN

• فرآیند Tiering

Tier‌هایی که از طریق LUN در سطوحی مختلف تعیین شده و از طریق محدوده‌ی اندازه LUN محدود می‌شوند.

• Storage IO Control

قابلیت تنظیم توسط مدیران به منظور کنترل بار شبکه VMها

بررسی ویژگی‌های SAN و NAS فعال شده با Virtual Volume

• VMFS

غیر ضروری است.

• (vSphere API for Storage Awareness (VASA

قابلیت‌های Storage را می‌توان از طریق پروفایل‌های فعال Policy و مرتبط با Object‌های هر یک از ماشین‌های مجازی بدون نیاز به LUNها یا Volumeها کنترل و ارائه نمود. برای مثال، فرآیند Replication برای Array را می‌توان بر حسب نیاز ماشین مجازی بر روی حالت On یا Off تنظیم نمود. لازم به ذکر است که VVols از VASA 2.0 استفاده می‌نماید.

• (vSphere API for Array Integration (VAAI

یکپارچگی با VVols

• قابلیت Profile-Driven Storage در vSphere

دارای روند تکاملی به سمت مدیریت مبتنی بر Policy در vSphere Storage یا به اختصار SPBM می‌باشد و همچنین به پشتیبانی از فرآیند Tagging برای Storageهای سنتی و خودکار‌سازی مبتنی بر Policy برای Storageهای مبتنی بر نرم‌افزار ادامه می‌دهد.

• Storage DRS

در صورت پشتیبانی از سوی vendorهای Storage، دارای قابلیت اجرا در سطح Virtual Volumeها خواهد بود. با Storage DRS می‌توان برنامه‌های کاربردی یا VMها را به منظور دستیابی به برخی نیاز‌های کسب و کار منتقل نمود.

• فرآیند Tiering

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

• Storage IO Control

در صورت پیکربندی، به کاربران نهایی امکان ایجاد Thresholdهای عملکرد در سطح Virtual Volume داده می‌شود.

Virtual Volumes، پروتکل‌های دسترسی به Storage و یا سایر فایل سیستم‌های موجود که توسط vSphere پشتیبانی می‌شوند را جایگزین نمی‌کند. در صورت نیاز، زمینه برای کاربرد VMFS در vSphere مهیا بوده و پشتیبانی می‌گردد و همچنین این پلتفرم قادر است به طور هم‌زمان به Virtual Volumeها و Arrayهای سنتیِ SAN و NAS مبتنی بر LUN نیز متصل گردد.

بسته به نحوه پیاده‌سازی Vendor ممکن است یک Array واحد بتواند از VVols و عملیات‌های مبتنی بر LUN پشتیبانی نماید. VVols از جهت محدودیت‌های تکنیکی و تاثیر عملیاتی نسبت به راهکارهای سنتیِ Storage دارای مزایای زیادی است.

Virtual Volumeها و SPBM به ارائه مزایای Storage مبتنی بر نرم‌افزار برای Arrayهای SAN و NAS از طریق فعال‌ نمودن روند آماده‌سازی مبتنی بر Policy و کنترل سرویس‌های Storage برای ماشین‌های مجازی می‌پردازد که از قابلیت Native Array بهره می‌برند.

همچنین این تکنولوژی به ارائه دیسک‌های مجازی به عنوان Storage Container Native پرداخته و عملیات Granular مبتنی بر Array را در سطح دیسک مجازی میسر می‌سازد. خودکارسازی و ایجاد VM به عنوان واحد داده موجب سادگی جریان‌های کاریِ Storage و کارایی بیشتر Arrayهای اصلی به‌ می‌گردد.

Virtual Volumes اقدامی مبتکرانه در صنعت محسوب می‌گردد که توسط تمام Vendorهای اصلی پشتیبانی شده و آماده‌سازیArrayهای SAN و NAS در محیط‌های vSphere را چابک‌تر و ساده‌تر نموده و هزینه‌های Storage را نیز کاهش می‌دهد.