Veeam Scale-Out Backup Repository

Veeam Scale-Out Backup Repository

شما می توانید Scale-Out Repository را به عنوان یکی از کابردی ترین خصوصیات نرم افزار Veeam در زیرساخت پشتیبان گیری پیکربندی کنید. Scale-Out Repository به صورت Logical تنظیم و راه اندازی می شود. با همبندی چند Repository در کنار هم فضای قابل استفاده را افزایش می دهد و شما در هر زمانی می توانید فضای در اختیار را بزرگ نمایید. هنگامی که شما Scale-Out Repository را پیکربندی می کنید، شما در واقع یک مجموعه ای از دستگاه های ذخیره سازی و سیستم ها را ایجاد می کنیدکه ظرفیتی معادل مجموع Repository ها برای شما در قالب یک Volume فراهم می نماید.

با استفاده از این قابلیت شما می توانید در هر زمانی فضای در حال استفاده را افزایش دهید به عنوان مثال اگر فضای شما در حال پر شدن باشد ، می توانید با ایجاد یک فضای جدید و اضافه کردن آن به گروه Scale-Out Repository ،بدون کوچکترین مشکلی فضا را افزایش می دهید و دیگر لازم نیست دیتاهای قبلی را جا به جا نمود.

برای ایجاد Scale-Out Repository می توان چندین Repository از جنس های متفاوت را با هم تجمیع و در یک Scale-Out Repository ارائه کرد که این خصوصیت Veeam با Repository های زیر سازگار می باشد:

  • Microsoft Windows backup repositories
  • Linux backup repositories
  • Shared folders
  • Deduplicating storage appliances

این امکان وجود دارد که به عنوان مثال یک Microsoft Windows backup repositories  و یک Deduplicating storage appliances را در یک فضا تجمیع و استفاده نمود.

در این نوع Repository انواع راهکارهای پشتیبان گیری و بازیابی اطلاعات قابل استفاده می باشد.

توصیه های ESXI در خصوص SAN Multipathing برای دستیابی به بالاترین میزان عملکرد

توصیه های ESXI در خصوص SAN Multipathing برای دستیابی به بالاترین میزان عملکرد

سیاست های SAN Path، می تواند تاثیر قابل توجهی بر روی عملکرد ذخیره سازی داشته باشد. به طور کلی سیاستی که ESXI به طور پیش فرض برای یک آرایه خاص استفاده می کند، بهترین انتخاب خواهد بود. اگر سیاست های غیر پیش فرض را انتخاب می کنید، توصیه می کنیم از میان پالیسی های تست شده و پشتیبانی شده توسط فروشنده ی ذخیره ساز خود انتخاب کنید. در این بخش خلاصه ای از پالیسی های SAN Path را مطرح می کنیم.

توصیه های ESXI

  • برای اکثر آرایه های ذخیره سازی فعال / غیرفعال، ESXi به طور پیش فرض از پالیسی بیشترین مسیر اخیرا به کار رفته (MRU) استفاده می کند. ما توصیه نمی کنیم که از سیاست مسیر ثابت برای آرایه های ذخیره سازی فعال / غیرفعال استفاده کنید، به این دلیل که این می تواند موجب تعویض مسیر مکرر و سریع شود و می تواند در دسترسی به LUN کندی ایجاد کند. برای عملکرد مطلوب با آرایه هایی که ESXi به طور پیش فرض به MRU می پردازد، شما ممکن است پالیسی Round Robin را در نظر بگیرید. برای برخی از آرایه های active/passive که ALUA را پشتیبانی می کند، ESXI می تواند از پالیسی مسیر ثابت استفاده کند. اما توصیه می شود از آن زمانی استفاده کنید که توسط vendor شما پشتیبانی شود. در اکثر موارد پالیسی Round Robin برای آرایه های active/passive انتخاب بهتر و امن تری است.
  • برای اکثر آرایه های ذخیره سازی فعال/فعال، ESXI به طور پیش فرض از پالیسی مسیر ثابت استفاده می کند. زمانی که از این پالیسی استفاده می شود شما می توانید استفاده از پهنای باند خود را با تعیین مسیر های مورد نظر به هر LUN از میان کنترلرهای مختلف ذخیره ساز به حداکثر برسانید. برای دستیابی به عملکرد مطلوب با این آرایه ها شما ممکن است از پالیسی Round Robin استفاده کنید.
  • ESXI می تواند از پالیسی Round Robin که می تواند performance ذخیره سازی را در برخی محیط ها بهبود دهد، استفاده کند. پالیسی Round Robin، Load Balancing را میان تمامی مسیر های فعال فراهم می کند و تعداد درخواست های I/O ثابت یا قابل تنظیمی را به هر مسیر active می فرستد. همه ی آرایه های ذخیره سازی Round Robin را پشتیبانی تمی کنند، استفاده از پالیسی هایی که توسط vendor ذخیره ساز پشتیبانی نمی شود می تواند مشکلاتی را در ارتباط با دسترسی به LUN به وجود آورد. توصیه می شود داکیومنت های مربوط به vendor حتما بررسی شود و در صورت پشتیبانی از Round Robin و توصیه به استفاده از آن توسط Vendor، از آن بهره ببرید.
  • ESXI همچنین از third-party path selection plugins(PSPs) نیز پشتیبانی می کند. این ممکن است بهترین Performance را برای یک آرایه ی خاص با بهره برداری از یک ویژگی خاص و دانش طراحی آن فراهم کند.
  • اگر ذخیره ساز شما قابلیت ALUA را پشتیبانی می کند، فعال کردن این ویژگی در برخی از محیط ها می تواند موجب بهبود performance گردد. ALUA که به طور خودکار توسط ESXI شناسایی می شود، اجازه می دهد که خود آرایه ی ذخیره سازی مسیری را به عنوان مسیر فعال بهینه تعیین کند. زمانی که ALUA با پالیسی Round Robin ترکیب می شود، ESXI به طور پیش فرض درخواست های I/O را از میان این مسیرهای active بهینه عبور می دهد.

(Veeam  (Backup Job Encryption

 (Veeam  (Backup Job Encryption

رمزنگاری برای Backup Job در نرم افزار Veeam  از قسمت تنظیمات پیشرفته مربوط به Job ها مطابق شکل زیر صورت می پذیرد.

در هنگام ایجاد و تعریف یک Job از Wizard مربوطه از قسمت Storage  بر روی گزینه تنظیمات پیشرفته Advanced کلیک می نماییم و پس از باز شدن صفحه جدید از زبانه Storage در قسمت Encryption  گزینه مربوط به رمزنگاری بکاپ ها را فعال می نماییم سپس بر روی گزینه Add کلیک کرده و رمز دلخواه خود را انتخاب    می نماییم.

توجه داشته باشید که می بایستی از رمز مورد نظر محافظت نموده و هرگز آن را فراموش ننمایید در غیر اینصورت بکاپ مورد نظر بلااستفاده بوده و قابلیت بازگردانی را ندارد.

مراحل فعال کردن رمزنگاری بر روی بکاپ ها بصورت زیر می باشد :

  • فعال کردن رمزنگاری برای بکاپ ها و مشخص کردن پسورد
  • نرم افزار Veeam Backup & Replication کلید لازم برای محافظت از بکاپ ها را تولید می کند.
  • نرم افزار Veeam Backup بلاکهای داده را درBackup Proxy رمزنگاری می کند و آنها را به            backup repository  انتقال می دهد.
  • در backup repository بلوک داده رمزگذاری شده به یک فایل پشتیبان تهیه شده ذخیره می شود.

Source : https://helpcenter.veeam.com/docs/backup/vsphere/encryption_backup_job.html?ver=95

قابلیت موجود در VMware به نام EVC

قابلیت موجود در VMware به نام EVC

بحث این مقاله در مورد قابلیت موجود در  VMware به نام EVC می باشد که با بحث VMotion  مرتبط است. زمانیکه شما می خواهید در یک Cluster در VMware ماشین های مجازی خودتان را از Host ای به Host دیگر منتقل کنید حتما باید نوع CPU سرور اول با نوع CPU سرور دوم مشابه باشد تا بتوانید به درستی VMotion را انجام دهید. این یک مشکل حاد در VMotion محسوب می شود چراکه همیشه Host های شما از یک نوع سخت افزار نیستند و بعضا ممکن است در یک Cluster  چندین Host مختلف با انواع CPU های مختلف داشته باشید که با این شرایط شما نمی توانید عملیات VMotion را انجام دهید. برای حل کردن این مشکل شرکت VMware بعد از معرفی محصول                 VMware ESX 3.5 Update 2   قابلیتی به نام EVC یا Enhanced VMotion Compatibility را معرفی نمود که برای برطرف کردن همین مشکل ارائه شده بود.

EVC  این قابلیت را به محیط مجازی سازی VMware می دهد که بتوانید VM های خودتان را بین Host های مختلف  ESXi  که دارای CPU های مختلف می باشندVMotion  کنید. روش کاری EVC به این شکل است که در هنگام انتقال یا VMotion کردن VM ها قابلیت های CPU ای که بین سیستم مبدا و سیستم مقصد یکسان نیستند و یا سیستم مقصد از آنها پشتیبانی نمی کند را از داخل VM ها حذف می کند تا به یک درجه مساوی از قابلیت ها برسد ، برای مثال مواردی از قبیل Clock Speed و یا تعداد Core های CPU را در بین Host ها تغییر می دهد تا با همدیگر تناسب پیدا کنند. این قابلیت با انواع نسخه های مختلف CPU که از یک سازنده و برند باشند کار می کند. به این مورد کاملا دقت کنید که VMware EVC نمی تواند بین پردازنده های AMD و Intel فرآیند VMotion را انجام دهد اما قبل از اینکه بخواهد فرآیند VMotion را انجام دهد سیستم Host اول و Host دوم را از نظر هماهنگ بودن نوع CPU ها با همدیگر بررسی      می کند و اگر عدم هماهنگی وجود داشته باشد به شما گزارش می دهد. البته به غیر از قابلیت EVC شرکت VMware یک قابلیت ساده تر به نامCompatibility Mask  CPU وجود دارد که با استفاده از آن می تواند برخی از قابلیت های CPU را از  VM  ها پنهان کند اما این قابلیت پیشنهاد نمی شود. درست است که EVC هم تقریبا چنین کاری انجام می دهد اما EVC همیشه هم نمی تواند باعث شود که VM نتواند به قابلیت های CPU دسترسی داشته باشد و این بستگی به نرم افزارها و Application  هایی دارد که بر روی ماشین مجازی نصب شده اند.

شما می توانید بصورت پیشفرض فقط VMotion را بر روی Host هایی انجام دهید که ساختار CPU های آنها یا کاملا مثل هم هستند و یا بسیار شبیه به هم هستند. این موضوع باعث می شود که سازمان در خرید کردن سرورهای جدید و اضافه کردن آنها در Cluster مجازی سازی خود کمی دچار مشکل شود. تصور کنید که شما در حال حاضر در سازمان خود یک سری سرور Host با برند HP مدل G6 دارید که بر روی آنها از قبل ESX نصب شده است و دارای سری خاصی از CPU های شرکت Intel هستند و در نهایت درون Cluster قرار گرفته اند. حال سازمان شما تصمیم می گیرد که برای رشدی که در آینده خواهد داشت ، یک سری سرور جدید برند HP مدل G9 را به مجموعه Cluster اضافه کندکه آنها هم برای خودشان دارای یک سری خاص CPU  هستند.

زمانیکه شما می خواهید عملیات VMotion را برای VM های این Host ها که دارای CPU های متفاوتی هستند انجام دهید اتفاقی که می افتد این است که در لایه سیستم عاملی که در VM نصب شده است ، VM دارای یک سری دستورالعمل ها و اطلاعات درون CPU است زمانیکه VMotion می شوند و در Host جدید قرار می گیرند به دلیل مشابه نبودن ساختار    CPU  قادر به اجرا و ادامه کار نخواهند داشت ، این موضوع باعث می شود که در سیستم عامل های ویندوز مجازی شما با صفحات Blue Screen و در سیستم عامل های لینوکس مجازی با مشکل Kernel Crash مواجه شوید ، دلیل بروز مشکل کاملا مشخص است ، دستورات و داده هایی که در CPU وجود داشتند به دلیل عدم هماهنگی بین CPU ها به یکباره دیگر در دسترس نخواهند بود.

برای جلوگیری از به وجود آمدن اینگونه Crash های سیستم عامل مجازی دو تکنیک مختلف استفاده می کند. اولین تکنیک زمانیکه مدیر شبکه درخواست انجام فرآیند VMotion را صادر می کند vCenter Server هم CPU مبدا و هم CPU مقصد را ارزیابی می کند و بررسی می کند که آیا هر دوی این CPU ها توانایی انجام شدن VMotion را دارند یا خیر ، اگر امکان انجام VMotion وجود نداشته باشد در همان لحظه به مدیر شبکه اطلاع رسانی خواهد شد. اما روش دوم که تا حدودی هم به آن اشاره کردیم به نام CPU Masking معروف است. CPU Masking کاری می کند که قابلیت هایی که بر روی CPU وجود دارند بر روی VM قابل مشاهده نباشند و در واقع به VM گفته نمی شود که CPU ای که از آن استفاده می کند چه قابلیت هایی دارد ، بنابراین سیستم عامل موجود در VM هم هیچ دیدی از نوع CPU ای که استفاده می کند نخواهد داشت این تکنیک باعث می شود که قابلیت های اضافه تری که معمولا باعث ایجاد شدن Crash در VM ها در زمان VMotion می شوند عملا از نظر سیستم عامل مجازی وجود نداشته باشد که باعث به وجود آمدن Crash بشود. اما تکنیک VMware Enhanced VMotion Compatibility یا EVC یک لایه از CPU Masking معمولی بالاتر است ، در CPU Masking قابلیت های  CPU  در لایه سیستم عامل مجازی مخفی می شود اما در EVC مخفی کردن یا CPU Masking در لایه Host انجام        می شود و طبیعتا در درجه بالاتری انجام می شود. دقت کنید که EVC هم بستگی به نرم افزارهایی دارد که از امکانات خاص CPU مثل CPUID استفاده می کنند ممکن است به درستی کار نکند و دچار مشکل شود اما تعداد نرم افزارهایی که به گونه ی برنامه نویسی می شوند که مثلا با قابلیت خاص CPU کار کنند بسیار معدود است و همین باعث می شود که EVC تقریبا بتواند در بیشتر موارد کار را به درستی انجام دهد.

توصیه های عمومی ذخیره سازی ESXI

توصیه های عمومی ذخیره سازی ESXI

تعداد LUN ها در یک آرایه ی ذخیره سازی و راهی که ماشین های مجازی در سراسر این LUN ها توزیع شده اند می تواند بر روی performance تاثیر گذارد. فراهم کردن LUN های بیشتر، با ماشین های مجازی کمتر بر روی هر یک، می تواند سرورهای ESXi را قادر سازد تا به طور همزمان درخواست های ورودی / خروجی بیشتری را به آرایه ذخیره سازی ارائه دهند. این قابلیت بالقوه ای برای بهبود عملکرد، با اطمینان استفاده کامل از تمام منابع آرایه و ارائه فرصت های بیشتری برای بهینه سازی I/O به آرایه ذخیره سازی است. از سوی دیگر ایجاد کردن LUN های خیلی زیاد، مخصوصا زمانی که سرورهای ESXI زیادی به یک ذخیره ساز تنها متصل شده اند، می تواند موجب شود هاست های ESXI به طور همزمان درخواست های I/O بسیار زیادی را که منجر به پر شدن صف آرایه ذخیره ساز و ارسال خطاهای QFULL/BUSY از سوی آرایه ذخیره سازی می شود. این مسئله می تواند موجب کاهش performance و نیاز به تلاش مجدد برای درخواست های reject شده شود.

آمار تاخیر در I/O را می توان با استفاده از esxtop و یا resxtor که گزارش زمان تاخیر دستگاه، زمان صرف شده در kernel و تاخیر دیده شده توسط سیستم عامل guest را می دهد، مانیتور کرد.

اطمینان حاصل کنید که تأخیر میانگین برای دستگاه های ذخیره سازی بسیار زیاد نیست. این تأخیر را می توان با مشاهده در esxtop و با جستجوی متریک GAVG / cmd. دید. مقدار معقول مناسب برای این معیار به زیر سیستم ذخیره سازی شما بستگی دارد. به طور پیش فرض storsge I/O control setting ، ۳۰ میلی ثانیه است اما اگر شما storage سریع تری دارید مثلا SSD، می توانید این مقدار را کاهش دهید.

شما می توانید حداکثر تعداد درخواست های دیسک را در هر VMFS Volume تنظیم کنید، که می تواند کمک کند پهنای باند ماشین های مجازی که از آن Volume  استفاده می کنند را برابر کنید.

اگر شما اغلب خطاهای QFULL / BUSY را مشاهده می کنید، ممکن است enable و تنظیم کردن عمق صف موجب بهبود عملکرد ذخیره سازی شود. این ویژگی می تواند به طور قابل توجهی تعداد دستورات برگشت داده شده از آرایه با خطای QFULL / BUSY را کاهش دهد. اگر هر سیستم دسترسی به یک LUN خاص یا پورت آرایه ذخیره سازی با queue depth throttling فعال شده دارند، تمام سیستم ها دسترسی به این LUN یا پورت آرایه ذخیره سازی باید از الگوریتم عمق صف استفاده کنند.

امکانات Veeam SureBackup

قابلیت Veeam SureBackup

یکی از نکته های مهم در تهیه پشتیبان از سرورها و سرویس ها ، اطمینان از عملکرد آن نسخه پشتیبان می باشد چرا که نیاز به پشتیبان همیشه در مواقع حساس پیش می آید و عملکرد صحیح آن به نوعی نجات از مرگ حتمی می باشد.

نرم افزار Veeam با درک اهمیت این موضوع قابلیتی با نام SureBackup راه اندازی نموده است. این قابلیت صحت عملکرد نسخه های پشتیبان را در محیطی ایزوله آزمایش می نماید و گزارشی از صحت عملکرد آن ارائه می نماید.

جهت استفاده از این قابلیت به موارد زیر نیاز می باشد:

  • Application Group : در زمان ریکاوری ماشین ها ، گاهی برخی از ماشین ها لازم است تا با هم شروع به کار نمایند تا بتوان عملکرد صحیح آنها را سنجید.در واقع گروهی از ماشین های وابسته به هم از لحاظ عملکرد می باشد.
  • Virtual Lab: محیطی ایزوله جهت اجرای ماشین های داخل Application Group می باشد که تست و عملکرد آنها بررسی می گردد.
  • SureBackup Job: در واقع یک Task که جهت اجرای صحت عملکرد عملیات ریکاوری ایجاد می گردد که هم به صورت Manual و هم به صورت Automatically Schedule قابل اجرا می باشد.

مراحل اجرا :

  • Veeam ابتدا ماشین ها را از قسمت Application Group با همان شکل فشرده شده که ذخیره شده است در محیطی ایزوله که معروف به Virual Lab می باشد به صورت Instant vm recovery فرا می خواند.
  • تست ها در سه مرحله­ برای VM Backup Files اجرا می شود که شامل Heartbeat Test ، Ping Test و Application Test می باشد.
  • در صورتی که Job مربوطه دارای صحت عملکرد باشد نرم افزار Veeam یک CRC Check ایجاد می کند شامل اینکه کدام ماشین استارت و تایید شده است و کدام VM Backup Files از کدام Application Group اجرا شده است و پس از اتمام مراحل ، تاییدیه مربوط به فایل پشتیبان صادر می گردد.
  • پس از اینکه عملیات بررسی صحت ریکاوری به اتمام رسید ، Veeam ماشین ها را اصطلاحا Unpublished می نماید و گزارشی تهیه و در صورت لزوم ایمیل می نماید.

لازم به ذکر است خصوصیت SureBackup  در لایسنس های Enterprise Plus  و Enterprise در دسترس می باشد.

Configuration Maximums در VMware VSphere 6.7

Virtual Machine Maximums

 

ESXI Host Maximums

Fault Tolerance Maximums

Vcenter  Server Maximums

Nutanix و محصول Acropolis؛ آیا vMware باید نگران شود؟

Nutanix و  محصول  Acropolis؛ آیا vMware  باید نگران شود ؟

Nutanix

 

حدود ۳ ماه پیش شرکت Nutanix محصول جدید خود به نام Acropolis را رسما معرفی کرد. Acropolis در واقع یک Hypervisor بر مبنای KVM است و همانگونه که انتظار می رفت هیاهوی بسیاری تولید کرد. ولی آیا vMware بعنوان یک رقیب باید به Acropolis نگاه کند و نگران باشد ؟

پاسخ کوتاه اینست که بله vMware لازم است که نگران باشد. البته بیش از نگرانی بابت رقیبی نظیر Acropolis باید از بابت عملکرد خود vMware  در قبال مشتریان و این صنعت نگران باشد! بالاترین تهدید Acropolis برای vMware را میتوان سادگی و استفاده آسان از آن دانست. به جرات می توان Nutanix را اولین شرکتی در این حوزه با این سهولت در بهره برداری، دانست.  اما تهدید که خود vMware مسبب آن است فراتر از اینهاست. سالهاست که مشتریان منتظر ورود قابلیتها خاص دیگر به محصولات vMware هستند، ولیکن تا کنون شاهد آن نبوده ایم. این در حالی است که دیگر رقبا در این عرصه توانسته اند تا حد بسیار زیادی قابلیت های موجود در vMware را در محصولات خود شبیه سازی نمایند. این توقف در ارائه قابلیتها از سوی vMware تا حدی باعث پراکندگی مشتریان vMware و جذب آنها به محصولات جدید شده است. دقیقا همان اتفاقی که برای Hyper-V مایکروسافت نیز افتاد. در ارائه اولیه Hyper-V نیز صحبت از قابلیتها بسیاری بود، ولی با گذشت زمان و عدم ارائه آنها از سوی مایکروسافت به دلایل بسیار، مایکروسافت کم کم بازار خود را در این حوزه به دیگر رقبا تحویل داد.

قطعا هنوز vSphere بدون هیچ شکی و یا ابهامی برترین Hypervisor این عرصه است و هنوز بهترین Ecosystem را در این صنعت در اختیار دارد. اما مدتی است که شاهد رکود نوآوری و ابداع در فضای Private Cloud ها می باشیم. امروزه کاربران با اشتیاق و سرعت کمتری نسبت به قبل به نسخ و ویرایش های جدیدvSphere ، خود را آپدیت میکنند و این هم عموما بدلیل فقدان قابلیت قانع کننده در ویرایش های جدید vSphere است. به عنوان نمونه ابزار vROPs یا همان vRealize Operation Manager ابزار خوبی است اما برای نیازهای بسیاری از کاربران بسیار بسیار پیچیده است و به هیچ وجه به سادگی و سهل استفاده بودن آن توجهی نشده است. با توجه به موارد ذکر شده ورودیهای جدید به بازار vMware نسبت به سالیان پیش رشد کمتری داشته و کم و بیش میتوان اظهار نمود که تقریبا متوقف شده است و این موضوعی است که Nutanix قصد دارد از آن بهره برداری نماید.

vMware  در این شرایط قصد دارد تا با فعالیتهایی نظیر Reworking Licensing، ترغیب مشتریان به خرید Suite های بزرگتر و بسط دادن بستر خود، به رشد دلخواه خود دست یابد. vMware بعد از چند قدم اشتباهی که برداشت، بطور واضح عکس العمل مشتریان خود را درک نمود. بسیاری از مشتریان vMware از مشتریان خرسند vMware به مشتریان ملزم و موظف vMware تبدیل شدند و این مشکل اصلی است.

حال باید دید آنها چگونه قصد دارند برتری خود را در این عرصه حفظ کنند. vMware نیاز دارد که مجددا تمرکز نماید. Nutanix توانسته تا با تمرکز بروی ظاهر، سادگی، انجام ساده کارها و در دسترس بودن آنها، برای مشتریان این بازار جذابیت بوجود آورد. توجه به نیاز مشتریان، این امری است که vMware به آرامی در حال فاصله گرفت از آن می باشد. شاید شرکت اپل بتواند به مشتریان خود بگوید آنها به چه چیزی نیاز دارند، زیرا مشتریان آنها، به اپل ایمان دارند، ولی شرکتهای بسیار کمی دارای این جایگاه نزد مشتریان خود هستند. ( و مطمئنا vMware هنوز در بین مشتریان خود این جایگاه را ندارد.)

و در پایان و بسیار شفاف من معتقدم که  vMware باید تلاش زیادی انجام دهد تا بتواند دید مشتریان خود را به پذیرش ترکیبی زیرساختهای “invisible” و vSphere در کنار یکدیگر، به عنوان یک سرمایه گذاری ارزشمند تغییر دهد.

معرفی PernixData Flash Virtualization Platform

معرفی PernixData Flash Virtualization Platform

فضای کاری Server-Side Flash Cache رو به داغ شدن است. در ابتدای امر این مجموعه Fusion I/O بود و پس از آن دیگر رقبا و … امروزه هم شرکت PernixData با ارائه محصولی با نام Flash Virtualization Platform و یا FVP وارد این بازار شده است.

بررسی محصول

نرم افزار FVP از شرکت PernixData به شما امکان Cache نمودن داده را بروی SDD های نصب شده بروی سرور برای شما فراهم می آورد. ممکن است با خود فکر کنید “خوب کی چی ؟؟”. vSphere نیز که خود این امکان را برای شما فراهم می آورد. درست است اما PernixData می تواند مزایای بسیاری برای شما فراهم آورد که در ادامه به بررسی آنها خواهیم پرداخت. اما اجازه بدهید در ابتدا یک بررسی اجمالی نسبت به محصول داشته باشیم. هدف این راهکار، افزایش سرعت عملکرد Storage است که با توجه با عملکرد آن بسیار مقرون به صرفه می باشد. این نرم افزار از Flash Memory موجود بروی سرور بعنوان یک Cache واسط میان سرور و تجهیز Storage بهره می برد. در ویرایش های اولیه این نرم افزار تنها امکان پشتیبانی از سرویس Block یعنی پروتکلها ISCSI , FC وجود داشت ولیکن در ویرایشهای بعدی پشتیبانی از سرویس فایل نیز به آن افزوده شد.

Cache نمودن داده ها بروی سرور دارای مزایایی می باشد. داده های Cache شده بسیار نزدیک هستند. بسیار بسیار نزدیک. IO مربوطه لازم نیست که از Fabric ( شبکه Storage ) عبور نماید. این شیوه باعث پاسخگویی سریعتر و Latency پایین تر می گردد و همچنین باعث کاهش ترافیک Storage و Fabric شما می شود. تجهیز Storage که با رشد خرنده Utilization و Load درگیر بوده و به حداکثر توان خود نزدیک شده است، با بهره گیری از این نرم افزار می توان بار کمتری را به تجهیز Storage تحمیل کرد و نتیجتا دارای طول عمر عملیاتی بیشتری شود.

تفاوت محصول PernixData با دیگر رقبا در چیست ؟

اول اینکه هر نوع Flash Memory قابل استفاده است. PCIe کارت ؟ دیسک SSD ؟ و یا … . همه قابل استفاده هستند و تنها در سرعت با یکدیگر متفاوتند. این موضوع به شما امکان بهره گیری از انواع مختلفی Flash Memory را فراهم نموده و می توانید میان هزینه و سرعت مورد نیاز خود، یک تعادل فراهم نمایید. بعنوان نمونه یک سرور Cisco USC B200M2 و یا یک سرور HP BL-460 G6 را در نظر بگیرید. هیچکدام آنها امکان استفاده از کارتهای Mezzanine جدید Fusion I/O را ندارند. در حالیکه هر دو سرور امکان استفاده از SSD های موجود در بازار را دارند و با استفاده از PernixData و SSD این سرورهای نسبتا قدیمی نیز می توانند از این مزیت بهره ببرند.

مزیت دوم اینست که PernixData برای شما هم امکان Read Cache را فراهم می آورد و هم Write Cache. در حالیکه پیشتر تمامی راهکارهای دیگر رقبا تنها به Read Cache منجر می شد. اکنون با این نرم افزار شما می توانید Write Cache  را برای همه یا یک ماشین خاص فعال نمایید. حال این سوال پیش می آید که چگونه Write Cache و دیتا های موجود بروی SSD های Local سرورها را از خطرات احتمالی محافظت نماییم؟ اگر قبل از انتقال داده های موجود بروی SSD به Storage، Host مربوطه از کار بیفتد، آنگاه تکلیف آن قسمت از داده ها چه می شود؟ PernixData به شما امکان محافظت از داده ها را می دهد. شما می توانید از این قابلیت با استفاده از تولید نسخ دوم و یا Write Back Peers بهره برده و یا در صورت عدم تمایل آنرا غیر فعال نمایید. انتخاب با شماست. در صورت استفاده از این قابلیت، PernixData از پورت vMotion جهت تبادل داده میان Host ها و تولید نسخ مزدوج داده ها استفاده می کند.

سومین تفاوت اینست که بعد از نصب و راه اندازی تمامی قابلیتها و ویژگیها vSphere شما بدون هیچ گونه اختلالی یا انجام تغییر و یا انجام تنظیمات خاصی قابل بهره برداری هستند و الزامی به انجام تغییرات بروی هیچ ماشین مجازی نمی باشد و تنظیمات آن از درون vCenter توسز Plugin مربوطه قابل دسترسی می باشد.

نصب

نصب محصول بسیار ساده است. تنها به یک سرور ویندوزی نیاز دارید تا کنسول مدیریتی را به روی آن نصب نمایید تا بتواند با Plugin درون vCenter ارتباط برقرار نماید. پس از آن باید یک Flash Cluster تولید نمایید و Flash های موجود بروی Host ها را به ان بیافزایید. آنگاه PernixData شروع به تولید PSPs یا  همان Path Selection Policy جهت تععین سیاست انتخاب مسیر می کند. بخاطر داشته باشید که اگر شما از PowerPath/VE استفاده می کنید نمی توانید آنرا همزمان با FVP داشته باشید.

نگاهی به قابلیت Flash Read Cache

نگاهی به قابلیت Flash Read Cache

یکی از قابلیتهای جدید و موثر افزوده شده به Vsphere 5.5 به بعد، ویژگی است، بنام Flash Read Cache که به اختصار به آن vFRC هم می گویند. این ویژگی به شما اجازه می دهد تا از SSD های موجود بروی Host های خود بعنوان Storage Read Cache استفاده نمایید. با این شیوه شما تمامی Workload های  مورد نیاز ماشین های مجازی خود را بروی یک SSD با سرعت بالا در کنار Host خود دارید و بدین گونه می تواند تاثیر مثبتی بروی عملکرد و سرعت کل کلاستر مجازی شما داشته باشد. بدین روش شما به یک Throughput بسیار مناسب با Latency بسیار پایین دست میابید. بهره گیری از قابلیت vFRC هیچ گونه تاثیر مخربی بر دیگر قابلیتها و فعالیتها ندارد. شاید این سوال برایتان پیش آید که آیا تمامی Host ها باید دارای SSD باشند تا بتوان از این قابلیت در کلاستر استفاده نمود؟ پاسخ این سوال خیر است. زیرا که اگر شما تنها یک Host با SSD هم داشته باشید می توانید از این ویژگی بهره ببرید و در صورت نیاز می توانید با vMotion ماشین مجازی را به Host که فاقد SSD باشد، منتقل نمایید تا با این تفاوت که ماشین مجاری بروی Host جدید دیگر نمی تواند از vFRC بهره ببرد. پس هیج گونه محدودیتی برای اجرا آن در کلاستر خود ندارید.

تصویر شماره ۱

شما می توانید حداکثر از ۸ دیسک SSD و یا حداکثر ۴ TB ، بروی هر Host و حداکثر تا ۳۲ TB برای کل کلاستر بهره ببرید. زمانی که شما این SSD ها را به Cache Pool خود اختصاص می دهید، کماکان می توانید از بخشی از فضای آن نیز بعنوان فضایی جهت Host Memory Caching استفاده نمایید. ( بمانند همان شیوه ای که در گذشته در Vsphere 5.1 استفاده می شد. )

نقطعه ضعفی که به vFRC وارد است اینست که شما تمامی تنظیمات مربوطه را باید مستقیما بروی تک تک ماشین های مجازی خود اعمال نمایید و امکان تعریف تنظیمات مشابه برای یک گروه ماشین وجود ندارد. این بدین معناست که شما باید برای هر ماشین مجازی علاوه بر فعال نمودن قابلیت vFRC، باید مقدار ظرفیتی را که می تواند از Cache Pool را در اختیار بگیرد تعیین نمایید. ( به خاطر داشته باشید که از این ویژگی تنها می توانید بروی ماشین های مجازی با Hardware Version 10 به بعد استفاده نمایید.)

پس از تعیین سایز فضای Cache بروی ماشین مجازی باید Block Size مربوطه را نیز تنظیم نمایید. Block Size در واقع تعیین کننده حداکثر فضای  Cache  قابل استفاده توسز ماشین مجازی است. مقادیر آن به شرح زیر است :

 

۴ K Block – Up to 4 GB

۸ K Block – Up to 8 GB

۱۶ K Block – Up to 16 GB

۳۲ K Block – Up to 32 GB

۱ MB Block – Up to 1 TB