آشنایی با EMC VNX Snapshot

  • درباره Snapshots

Snapshot تکنولوژی است که برای ما توانایی تولید یک “تصویر” از اطلاعات در یک نقطه از زمان را فراهم می آورد. درک این نکته مهم است که بدانیم که فرآیند Snapshot خود منتج به تولید یک کپی منفک و مستقل ازاطلاعات اصلی نمی شود و به هیچ وجه نمی توان به آن به عنوان یک شیوه Backup نگریست. اما می تواند ( با عمق های و شیوه های متفاوت نظیر snapshots و یا snapview و غیره ) توانایی حفظ اطلاعات را در یک نقطه از زمان فراهم آورد، پس بدین شیوه شما همیشه امکان عقب گرد به دقیقا همان وضعیتی که در آن Snapshot تولید شده است، را دارید.

 

  • بررسی اجمالی VNX Snapshot

VNX Snapshot تکنولوژی جدیدتر و کاملتر تکنولوژی موجود در رده های پیشین  EMC بنام SnapViwe Snapshot می باشد. در تکنولوژی جدید امکان یکپارچگی مناسب تری با Poll بوجود آمده است. VNX Snapshot تنها روی LUN های درون یک Pool قابل استفاده هستند.

LUN های تولید شده بروی RAID Group ها که LUN های کلاسیک نامیده می شوند، تنها SnapView را پشتیبانی می کنند. درک این محدودیت زمانی آسانتر خواهد شد که ما تفاوت میان VNX Snapshot و SnapView را بدانیم.

محدودیت دیگر اینست که VNX Snapshot و SnapView نمی توانند با هم بروی یک Pool همزیستی داشته باشند!

VNX Snapshot در ازای هر LUN امکان تولید ۲۵۶ عدد Snap را دارد. همچنین Branching را نیز پشتیبانی می نماید.

Branching که Snap Of A Snap نیز نامیده می شود، در واقع Snap های تو در تو است. بیاد داشته باشید که شما حداکثر تا ۱۰ مرحله می توانید Sanp Of A Snap داشته باشید.

 

  • VNX Snapshot چگونه کار می کند ؟

VNX Snapshot از تکنولوژی (Redirect On Write (ROW استفاده می کند. ROW با تغییر مسیر مقصد Write های جدی از LUN اولیه، به یک محل جدید در Pool، اقدام به تولید یک Snap می نماید. در حالیکه SnapView از تکنولوژی (Copy On First Write (COFW استفاده می کند. COFW که برای هر Snap اقدام به تولید یک کپی کامل و منفک از وضعیت فعلی LUN می نماید.

تصویر زیر به درک مناسب تر این موضوع کمک می نماید.

SnapView Snapshot vs VNX Snapshot – writes

 

تکنولوژی VNX Snapshot تمامی داده های جدید را در محلی جدید بروی Pool می نویسد، بدون اینکه نیاز باشد بروی Block قدیمی داده ها، عملیات Read/Write انجام دهد. این موضوع باعث افزایش عملکرد در مقایسه به SnapView می شود.

به همچنین، در هنگام خواندن داده ها از VNX Snapshot، داده های از دو محل مختلف جمع آوری و ساخته نمی شوند. تصویر زیر را ملاحظه فرمایید :

SnapView Snapshot vs VNX Snapshot – reads

اگر هاستی بخواهد داده ای را از یک LUN که توسط VNX SnapShop از آن Snap گرفته شده و به یک Snap خاص Mount شده را بخواند، داده را مستقیما از همان محل Snap شده می خواند و به وضعیت فعلی LUN مربوطه کاری ندارد. در حالیکه در SnapView بخشی از داده ها از Source LUN خوانده می شود.

 

  • Snapshot Granularity

هر VNX Snapshot دارای ۸kB Block Granularity می باشد. این بدان معناست که هر Write حداقل ۸ kB بروی Pool فضا اشغال می نماید. توزیع این Block های ۸kB بروی Slice های با سایز ۲۵۶MB، کاملا با الگوریتم Write بصورت Thin همراستا و متجانس است.

 

  • Snapshot و Lun های Thick

هنگامی که بروی یک LUN که Thick  است،  VNX Snapshot تولید می کنید، بخشی از آدرسهای مربوط به فضای قابل استفاده به Indirect Mode تغییر خواهند کرد. به عبارت دیگر، زمانی که داده های جدید نوشتنی به یک Thick LUN که Snap دارد وارد می شود، LUN شروع به تغییر آدرس ها و Map کردن آنها برای هر Block با سایز ۸ kB می کند. Thick LUN تا زمانی که دارای Snap می باشد در همین حالت Indirect Mode باقی خواهد ماند. زمانی که آخرین Snapshot یک Thick LUN حذف شود، آنگاه بصورت خودکار به حالت Direct Mode بر می گردد.

 

  • Snapshot Mount Point

(Snapshot Mount Point (SMP یک Container ( ظرف ) شبیه LUN است.  از SMP برای شبیه سازی یک Typical LUN استفاده می شود. تنها با این تفاوت که برای یک هاست توانای نوشتن و تغییر بروی Snapshot را بدون نیاز به Rescan SCSI Bus توسط هاست، فراهم می آورد. هر SMP تنها برای یک Snapshot از یک LUN تولید می شود. این بدان معناست که هر SMP می تواند تنها برای یک Snapshot از یک LUN مورد استفاده قرار گیرد. برای استفاده هاست از داده های موجود بروی SMP، SMP مربوطه باید به Storage Group مربوطه افزوده شود.

Snapshot Mount Point

تبدیل یک VNX Snapshot به Standard LUN

 

یک از موارد مورد استفاده از VNX Snapshot ، ارائه نمودن یک Snapshot بعنوان یک Standard LUN است. برای انجام اینکار، یک Snapshot باید متصل شود، آنگاه SMP را می توان به یک LUN دیگر Migrate نمایید. اگر SMP که Migrate میکنید، خود دارای Snapshot های دیگری باشد، ( برای مثال Snapshot های تو در تو ) همه آن Snapshot ها حذف می شوند.

 

  •  Mount SMP To Another Host

Mount SMP To Another Host

 

تصویر فوق را در نظر بگیرید :

  • Host1 یک سرور عملیاتی است که PrimaryLUN1 به آن ارائه شده و نرم افزار هایی را با آن LUN در حال اجرا دارد.
  • Host2 یک سرور بخش توسعه نرم افزار است. این سرور باید یک نسخه جدید نرم افزار را با استفاده از داده های عملیاتی اجرا نماید.

شما باید فعالیتهای زیر را انجام دهد :

  1. یک Snapshot ( مثلا Snap2 ) از Lun عملیاتی PrimaryLUN1 بگیرید.
  2. یک SMP از Snapshot مربوط به PrimaryLUN1 تولید نمایید.
  3. SMP تولید شده را به Host2 ارائه نمایید. ( SMP را به Storage Group مربوط به Host2 اضافه نمایید.)
  4. Snap2 را به SMP متصل کنید.
  5. SCSI را روی Host2 را Rescan نمایید.
  6. یک دیسک Local بروی سرور Host2 تولید نمایید.
  7. از برخی نقطه نظرات SMP خود Snap می شود و ۱ تولید می شود.

 

بعد از اجرای موارد مختلف توسعه بروی نرم افزار، تصمیم گرفته می شود که بصورت یک LUN مستقل ارائه شود. برای انجام این کار فرآیند ذیل را پی بگیرید :

  1. یک LUN جدید با همان سایز PrimaryLUN1 بسازید ( مثلا LUN Temp ). در نظر داشته باشید که الزامی نیست که LUN جدید حتما یک Pool LUN باشد و یا حتما در همان Pool مربوط به PrimaryLUN1 باشد.
  2. یک Session برای Migration از SMP Name به LUN Temp اجرا نمایید.
  3. زمانی که Migration به انتها رسید مجموعه ای از چیزهای مختلف رخ می دهد :
  • Snapshot که به SMP Name متصل بود، حذف می گرد.
  • LUN temp به SNP تغییر نام داده می شود و همه خصوصیات SCSI مربوط به Mount Point شامل WWN و حتی HLU-ID حفظ می شود.
  • Snap2.1 از بین می رود.

LUN Migration Of SMP

 

 

پشتیبانی EMC VNX از vMware

یکپارچگی میان vCenter و Unisphere می تواند مدیریت Storage را در محیط های مجازی بسیار ساده تر و روان تر نماید. EMC برای بهینه سازی کامل محصولات رده VNX خود با محیط های مجازی، VMware vStorage API for Array Integration و یا همان VAAI، را معرفی کرده است. این تکنولوژی بار تحمیلی از بابت تمامی عملیات مرتبط با امور ذخیرشی vMware را از روی سرور برداشته و بروی تجهیز Storage قرار می دهد. بدین گونه استفاده موثرتر از منابع سرور، خود سرور و منابع شبکه را جهت افزایش عملکرد و تثبیت شرایط، مهیا می نماید.

رده VNX همچنین (VMware vStorage API for Storage Awareness (VASA را پشتیبانی می کند که به تجهیز VNX اجازه می دهد که با vCenter Storage Profile ها ارتباط برقرار نماید.

سرورهای ESXi عموما به یک تجهیز VNX با سرویس Block از طریق FC،  FCoE و iSCSI متصل می شوند. این تجهیز Block یک LUN را برای تولید VMFS datastores در اختیار هاست ESXi قرار می دهد. هاست از این فضا جهت ماشینهای مجازی و یا بعنوان یک (Raw Device Mapped (RDM برای یک ماشین مجازی استفاده می کند. البته بیاد داشته باشید که ESXi می تواند از طریق NFS نیز به یک VNX با سرویس File نیز، متصل شود.

 

  • EMC VSI

(EMC Virtual Storage Integrator (VSI ویژگی است برای ساده سازی مدیریت تجهیزات EMC در رده VNX . این قابلیت به vMware Admin اجازه تولید Datastore های NFS و یا VMFS و همینطور تولید RDM، مستقیما از درون vSphere Client می دهد. ( VSI نسخه مخصوصی برای vSphere Web Client نیز دارد.)

 

  • VAAI

 

(vStorage API for Array Integration (VAAI یک API است که برای حذف بار عملیات مربوط به امور ذخیرشی از روی هاستهای Esxi طراحی شده است. بدین ترتیب تجهیز Storage شما بعنوان یک سخت افزار شتاب دهنده برای امور ذخیرشی هاستها ESXi شما عمل می نماید. حذف بار امور ذخیرشی از روی سرورهای ESXi، باعث کاهش مصرف CPU، Memory و پهنای باند Fabric ( شبکه Storage ) می شود. بدین گونه است که بهره مندی از این قابلیت، به هاستها اجازه می دهد تا از توان پردازشی خود تنها برای ماشینهای مجازی بهره ببرند و این به معنای عملکرد بهینه تر است.

 

  • VAAI Operations

 

  • Array Accelerated Bulk Zero : همانگونه که می دانید در فایل دیسک یک ماشین مجازی ( VMDK ) هم فضای مصرف شده وجود دارد و هم فضای خالی. زمانی که از یک ماشین مجازی Clone می گیرد، این قسمت خالی نیز کپی می شود، که این خود مسبب تولید بسیاری فعالیتهای اضافی SCSI برای یک فضای خالی می شود. فرآیند Block Zeroing باعث کاهش دستورات و عملیات SCSI بروی سرور می گردد و تجهیز Storgae مسئولیت تولید این حجم بزرگ از داده های صفر ( جهت فضای خالی دیسک مجازی ) را بر عهده می گیرد و سرور ESXi تنها به هنگام Clone فضای پر دیسک مجازی درگیر امور ذخیرشی خواهد بود.
  • Full Copy : در هنگام تولید یک ماشین مجازی از یک Template، تمامی بار مربوط به امور ذخیرشی مستقیما توسط تجهیز Storage  صورت می گیرد و به هیچ وجه از منابع هاست استفاده نمی شود.
  • Hardware Locking : حجم بار مکانیزم VMFS Volume Lock کاملا به تجهیز Storage منتقل شده و حتی در Sub Volume ها نیز اجرا شده است. این بمعنای استفاده بهینه تر از VMFS Volume به اشتراک گذاشته شده توسط کلاستر vMware است.
  • Thin Provisioning : وقتی که یک VM حذف می شود و یا از یک Thin LUN Datastore به محل دیگری Migrate می کند. فضای که استفاده شده بود، به فضای قابل استفاده در Pool اضافه می شود.
  • Stun And Resume : زمانی که یک Thin LUN بدلیل استفاده فضا توسط یک VM، پر می شود، آن VM برای جلوگیری از بروز اختلال در آن، Pause می گردد.و یک هشدار نیز برای Storage Administrator تولید می گردد.

 

 

  • VASA

 

(The VMware Aware Storage API (VASA یک قابلیت ویژه و یک پروتکل برای vMware است و از پروتکل لایه http برای ارتباط با محیط Storage بهره می برد.

VASA برای انتقال قابلیتهای Storage به درون vCenter طراحی شده است. VNX قادر است تا قابلیتهای نظیر وضعیت SPها، LUNها، I/O موجود بروی پورتها و فایل سیستم  را به درون vCenter بیاورد. همچنین نمایش وضعیت سلامتی تجهیز، ظرفیت و هشدارها نیز از این طریق در vCenter  قابل دسترسی می باشند.

جنبه کلیدی یکپارچگی با API اینست که، قابلیت تولید و استفاده از Profile برای تنظیمات وجود دارد. در این وضعیت شما می توانید با تولید یک Storage Profile برای نیازهای یک VM خاص طراحی نماید و زمانی که یک vMotion و یا Clone انجام دهید، Profile می تواند بر اساس تجهیز مقصد خود را تغییر دهد.

 

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

Storage Profiles همچنین به هنگام استفاده از Datastore Cluster در حالتی که SDRS فعال باشد، مورد استفاده قرار می گیرند. زمانی که Profile بخشی از Datastore Cluster می باشد، SDRS جانمایی داده ها را روی Datastore کنترل می کند.

قابلیتهای Storage همچنین در موارد دیگر نظیر تولید VM جدید، Migrate کردن VM نیز استفاده می شود.

 

معرفی Access Logix، LUN Masking و Storage Groups

 

Access Logix یک نرم افزار لایسنس دار برای Storage ها می باشد که قابلیت امکان دسترسی به داده ها درون تجهیز Shared Storage را از طریق Storage Group ها فراهم می آورد. این نرم افزار بروی تمامی Storage Processor ها فعال است.

 

Access Logix functionality :

  • LUN Masking : فرآیند است که طی آن یک LUN برای تعدادی از هاست قابل دسترس و برای دیگر هاستها غیر قابل دسترسی می شوند. در ادامه در این خصوص اطلاعات بیشتری ارائه خواهد شد.
  • ‘Presents a ‘virtual storage system : با LUN Masking، LUNها تنها توسط سرورهایی که تایید شده اند قابل دسترسی هستند. در واقع با این شیوه یک Virtual Storage System تولید و به هر هاست عرضه می شود.
  • Maps VNX LUNs to host LUNs :ا Lun های VNX را که معمولا Array Logical Units و یا ALUs می نامند به LUN های هاست که Host Logical Units و یا HLUs نامیده می شود، متصل می نماید.
  • Manages Access Control List : دسترسی به LUN توسط اطلاعاتی که در جدول Access Logix نگهداری می شود، بررسی می شود. این جدول در یک فضای از پیش تعیین شده بروی دیسکهای VNX، بنام PSM LUN یا همان Persistent Storage Manager وجود دارد.

 

  • محدودیتهای Access Logix
  • هر هاست تنها می تواند در یک Storage Group در ازای هر Storage System حضور داشته باشد.
  • یک هاست می تواند حداکثر در چهارStorage System  حضور داشته باشد.
  • تعداد هاستهای قابل پیش بینی در هر Storage System بستگی به مدل VNX دارد.
  • هر Storage Group تولید شده تنها بصورت Localy و بروی همان Storage System اعتبار دارد.
  • حداکثر تعداد LUN درون یک Storage Group، بستگی به مدل VNX دارد. به عنوان نمونه این عدد برای VNX 5500 برابر ۵۱۲  است.

 

  • Storage Group :

Storage Group مجموعه است از یک یا چند LUN که به یک یا چند هاست متصل شده است. به عبارت دیگر Storage Group بمانند یک یک ظرف است که در زمان تعریف آن :

  • لیستی از سرورها را در آن ظرف قرار می دهید.
  • لیستی از LUN ها را در آن ظرف قرار می دهید.

 

تمامی سرور ها که درون یک Storage Group هستند می توانند به تمامی LUN های درون آن، دسترسی داشته باشند. این فرآیند LUN Masking نام دارد.

 

LUN Masking  و  LUN Mapping

دیاگرام زیر یک Storage System را نمایش می دهد که به دو هاست متصل است. هر هاست یک Storage Group دارد. Storage Group A برای سرور A و Storage Group B برای سرور B . LUN های مورد استفاده بروی Storage Sysytem بصورت پیاپی از شماره ۰ الی ۷ می باشند. اما همیشه این اعداد بدین گونه پی در پی نیستند. ALU همان Array Logical Unit و HLU همان Host Logical Unit است. هر LUN بروی Storage System با یک LUN Number منحصر بفرد توسط هاستها دیده می شوند. این فرآیند اعطای شماره منحصر بفرد به هر LUN را LUN Mapping گویند.

 

این شماره دهی به LUN ها در یک جدول Translation که قسمتی از پایگاه داده Access Logix است نگه داری می شود.

Pool LUNs چیست ؟ تفاوت Thin و Thick  در چیست ؟

مفهوم Pool LUN را پیشتر در آموزش ” FAST VP چیست ؟ ” ارائه شد  ولیکن اکنون قصد دارم کمی عمیق تر به بررسی و تحلیل این مفهوم بپردازم تا این مفهوم برای همه کاملا قابل درک شود.

Pool LUN کاملا شبیه  Traditional LUNاست. برای مثال تمامی فعالیتهای Unisphere و یا دستورات قابل استفاده در Secure CLI هم برای Pool LUN و هم برای Traditional LUN قابل استفاده است.

تنها تفاوت اصلی میان این دو عبارتست از اینکه Traditional LUN مستقیما بروی یک Raid Group تولید شده اند در حالیکه Pool Lun ها یک اندازه منطقی هستند که از طرفیت Pool گرفته شده است. تولید LUN بروی یک Pool به ما قابلیتهای زیادی نظیر FAST VP ( در اینجا به آن اشاره شده است ) و یا انتخاب بین Thick و یا Thin را برای ما فراهم می آورد. بیاد داشته باشیم که Traditional LUN همیشه بصورت Thick هستند.

 

  • Thin LUN

تفاوت اصلی Thin LUN در مقایسه با Traditional LUN و یا Thick LUN ها در اینست که Thin Lun ها می توانند فضایی بیش از فضای فیزیکی یک Storage در اختیار نرم افزار ها و هاستها قرار دهند. این یعنی چه ؟ اجازه دهید با یک مثال این موضوع را برای شما توضیح دهم. فرض کنیم Admin لینوکس به یک LUN با ظرفیت ۶۰۰GB نیاز دارد، ما یک  LUN از نوع Thin ساخته و در اختیار هاست قرار می دهیم. اگر این هاست لینوکسی تنها از ۳۰% ظرفیت خود استفاده نماید، یعنی حدود ۲۰۰GB ، آنگاه ۴۰۰GB دیگر موجود بروی Storage، کماکان توسط یک هاست دیگر قابل بهره برداری است. در حالیکه اگر از Traditional LUN و یا Thick LUN ها استفاده کنیم، استفاده هاست دیگر از فضای بلا استفاده هاست لینوکسی مقدور نیست.

این قسمت خوب این راهکار است. ولیکن بایستی بیاد داشته باشیم که اینگونه LUN ها دارای عملکرد و سرعت پایین تری نسبت به Lun های Thick هستند.

 

  • Thick LUNs

به هنگام ساخت Thick LUN ها، فضای مربوطه بصورت کامل از فضای فیزیکی موجود بروی Storage کسر می شود و در اختیار این گونه LUN ها قرار می گیرد. این بدان معناست که تمامی Slice های مورد نیاز ( تولید شده در فرآیند تولید  Pool )، به LUN مربوطه اختصاص داده می شوند. یک Pool می تواند هم شامل LUN های Thin باشد و هم LUN های Thick . در هنگام بهره گیری از FAST VP، استفاده از LUN های Thick، پیامد و عملکرد مناسب تری دارد.

ساخت یک LUN بصورت Thin بسیار ساده است. با توجه به تصویر فوق به هنگام تولید یک LUN و با علامت گذاری Check Box نمایش داده شده در تصویر فوق، آن LUN به Thin تبدیل می شود. به همین سادگی. در اینجا لازم است مفهوم دو مقدار موجود در این قسمت را برای شما شرح دهم :

  • User Capacity : حداکثر فضای قابل استفاده توسط کاربر. در تصویر فوق این عدد برابر است با ۱۲۵۵۰.۴۶۵GB .
  • Consumed Capacity – مقدار فضای استفاده شده توسط کاربر. در تصویر فوق این عدد برابر است با ۵۹.۱۱۵ GB .

 

۲۵۸۰۲۲۶.VMware vCenter Site Recovery Manager 6.0.0

VMware vCenter SRM یک راه حل مدیریتی DR پیشرو در مجازی سازی مبتنی بر VMware است. SRM امکان هماهنگ‌ سازی (Orchestration) خودکار و بررسی بلادرنگ طرح‌های بازیابی متمرکز را، برای همه برنامه‌های مجازی‌سازی شده پدید می‌آورد.

SRM به گونه ای طراحی شده که می‌‌تواند با vSphere Replication ادغام شده و همچنین مجموعه‌ی وسیعی از محصولات Array-Based Replication را پشتیبانی نماید.

ایجاد ساختار براساس vSphere و تکمیل آن با SRM می‌تواند هزینه‌ی (DR(Disaster Recovery یا بازیابی پس از بحران را از طریق اتوماسیون مدیریت کارکرد و بررسی خودکار، به شدت کاهش داده و پیچیدگی پردازش‌های قدیمی‌را از بین می‌برد و این در حالی است که قابلیت پیش‌بینی سریع زمان بازیابی RTO تداوم کسب و کار را تضمین می‌نماید.

فایل ها همانند همیشه از VMware مستقیماً تهیه شده و با نام اصلی و بدون هیچ دخل و تصرفی در اختیارشما قرار میگیرد.

 

Link 1 : VMware-srm-6.0.0-2580226.exe

Link 2 : VMware-srm-6.0.0-2580226.exe

Link 3 سرور ایران : VMware-srm-6.0.0-2580226.exe

File size: ۱۸۴.۵ MB

Password: www.vcloudtip.com

 

 

 

VMware vSphere Replication 6.0.0.0-2568808

VMware  یک Replication ساده و مقرون به صرفه را ارائه می کند. vSphere Replication اولین Replication صنعتی بر مبنای Hypervisor است که برای vSphere و Site Recovery Manager بنا شده است.  vSphere Replication میتواند از Storage های ناهمسان در سرتاسر سایت ها استفاده کند.

فایل ها همانند همیشه از VMware مستقیماً تهیه شده و با نام اصلی و بدون هیچ دخل و تصرفی در اختیارشما قرار میگیرد.

 

Link 1 : VMware-vSphere_Replication-6.0.0.0-2568808.iso

Link 2 : VMware-vSphere_Replication-6.0.0.0-2568808.iso

Link 3 سرور ایران : VMware-vSphere_Replication-6.0.0.0-2568808.iso

File size: ۱.۰۸ GB

Password: www.vcloudtip.com

 

 

 

FAST VP چیست ؟

 

FAST VP مخفف عبارت Fully Automated Storage Tiering for Virtual Pools است. یک راهکار هوشمندانه که بصورت پویا داده ها را با توجه به نرخ دسترسی به آنها، بروی لایه های مختلف Storage جابجا می نماید. FAST VP هارد دیسک ها را به ۳ لایه مختلف ( در آموزش Storage Pools در مقابل RAID Groups توضیحات لازمه ارائه شده است.  ) که به آنها Tier می گوید، تقسیم می کند :

  • Extreme Performance Tier – Flash drives
  • Performance Tier – ۱۵k and 10k SAS drives
  • Capacity Tier –  NL-SAS drives (که می توانند تا ۴ ترابایت فضا داشته باشند)

 

مزیت اصلی FAST VP کاهش هزینه کل نگهداری داده ها است. FAST VP با ترکیب هارد های گران و ارزان می تواند یک فضای با سرعت بالا تولید نماید. ایده اصلی بر اساس این واقعیت است که، تنها بخشی ( که عموما هم بیش از ۵% نمی شود ) از کل داده بصورت مداوم مورد دسترسی قرار می گیرد. بر این اساس ما می توانیم اینگونه از داده ها را که ” دارای فعالیت زیادی ” هستند را بروی لایه پر سرعت یک Heterogenous Pools قرار داده و مابقی داده ها را بر اساس نرخ دسترسی بروی لایه های بهدی توزیع نماییم. تصویر زیر قبل و بعد از از این عمل را نشان می دهد.

 

Tiering policies

FAST VP یک قابلیت خودکار است که با تبعیت از یک سری سیاستهای تعریف شده از سوی کاربر، از جانمایی صحیح داده ها و عملکرد مناسب Storage اطمینان حاصل می کند. FAST VP با بهره مندی از الگوریتم های پیچیده و با توجه به نرخ دسترسی به هر قسمت ( Slices )، در صورت نیاز اقدام به جابجایی بین لایه های مختلف خواهد کرد. برای این منظور شما می توانید در سطح یک LUN سیاست خود را تعیین نمایید. این سیاست ها عبارتند از :

 

  • Highest Available Tierاین سیاست زمانی که سریعترین Response Times اولویت مد نظر است، استفاده می شود. در این سیاست، با سریعترین Slices شروع می نماید و پس از اتمام ظرفیت سریعترین لایه، به سراغ لایه بعدی می رود.

 

  • Auto-Tier : عموما بخش کوچکی از کل داده های شما، مسبب درصد بزرگی از کل I/O تولید شده هستند. با بهره گیری از این سیاست، این درصد کوچک به سریعترین بخش Tier جابجا می گردد، در حالیکه ما بقی داده ها بروی همان بخش کم سرعت تر نگهدارای می شوند. سیاست Auto-Tier بصورت خودکار اقدام به جابجایی Slice ها بین Tier های مختلف می نماید. به هنگام کمبود فضا در هر Tier، سیاست Highest available Tier بر سیاست Auto-Tier ارجحیت دارد.

 

  • Start High then Auto-Tier : این سیاست، بعنوان سیاست پیش فرض هر LUN تولید شده است. این سیاست در ابتدا از مزایای Highest Available Tier بهره می گرد و آنگاه به سراغ سیاست Auto-Tier می رود. در این سیایت در ابتدا تمامی داده ها بروی سریعترین Tier جانمایی می شوند و آنگاه با توجه به نرخ دسترسی داده ها بروی Tierهای مختلف توزیع می شوند.

 

  • Lowest Available Tier : این سیاست زمانی اولیت پیدا می کند که هزینه کل نگهداری داده  مهم باشد. به همین دلیل داده بروی کم سرعت ترین Tier که کم هزینه ترین نیز می باشد، نگهداری می شود.

 

  • No Data Movement : این سیاست تنها پس از ساخت یک LUN قابل دسترسی است. همانگونه هم که از نام آن بر می آید داده ها همیشه در موقعیت فعلی خود باقی می مانند و جابجا نمی شوند. با این وجود EMC اقدام به جمع آوری داده های لازم جهت فرآیند Tiering می کند تا اگر در آینده خواستید سیاست را مثلا به Auto Tier تغییر دهید، Storage داده های لازمه را در اختیار داشته باشد.

 

Data Relocation

Data relocation فرآیند جابجایی داده ها میان Tier ها مختلف موجود در یک Pool است. این فرآیند بر اساس Tiering Policy و داده های جمع آوری شده از نرخ دسترسی به Slice های LUN صورت می گیرد. شما می توانید با استفاده از قابلیت Relocation Schedule، این فرآیند را زمانبدی نمایید و یا حتی این فرآیند را کاملا بصورت دستی انجام دهید. مقادیر مختلف وضعیت عملکرد فرآیند Data Relocation عبارتند از:

  • Ready – هیچ فرآیند جابجایی داده ای در جریان نیست.
  • Relocating –  در حال اجرای فرآیند جابجایی داده است.
  • Paused – فرآیند جابجایی داده متوقف شده است.

 

همان گونه که پیشتر نیز اشاره شد، قابلیت FAST VP جابجایی خودکار داده ها را میان Tier های مختلف، بر اساس سیاست های از پیش تعیین شده و بر اساس برنامه زمانبندی شده، را داراست. برنامه زمانبدی به شما امکان تعریف نرخ سرعت جابجایی را می دهد. مقادیر عبارتند از :

  • Low
  • Medium
  • High

Low دارای کمترین تاثیر بر عملکرد Storage است و High دارای بیشترین تاثیر بر عملکرد Storage است. گزینه پیش فرض Medium است.

 

استفاده از FAST VP در محیط File

برای تولید یک Filesystem در VNX، شما باید یک LUN را از محیط Block برای این منظور تدارک ببینید و آن را در Storage Group با نام filestorage~ قرار دهید. اگر LUN تولید شده در محیط Block با بهره گیری از FAST VP تولید شده باشد، آنگاه File System نیز که از آن LUN استفاده می کند، دارای قابلیتهای FAST VP است. تصویر زیر گویای این موضوع است.

 

FAST Cache چیست ؟

 

 

می توان FAST Cache را با ” DRAM cache ” مقایسه نمود، تنها باید بخاطر داشته باشید که FAST Cache از Flash دیسک ها ساخته شده  است، پس دارای ظرفیت بسیار بیشتری است. و در مقابل DRAM Cache دارای سرعتی بمراتب بیشتر از FAST Cache می باشد.

 

  • DRAM cache : بخشی از Storage است که باعث افزایش عملکرد Storage می شود. نحوه عملکرد آن بدین گونه است که بصورت Trasparent ( شفاف و نامحسوس ) داده ها را در بروی یک Storage بسیار پرسرعت ( DRAM ) ذخیره می نماید و آنگاه به هارد دیسک ها منتقل می کند. این فرآیند باعث افزایش سرعت سامانه می شود. اما این گونه Cache ها بدلیل قیمت بسیار گزاف DRAM ، از لحاظ ظرفیت بسیار محدود هستند.

 

  • FAST Cache : تکنولوژی مکمل برای DRAM Cache است. این تکنولوژی به شما امکان بهره برداری از ظرفیتهای Cache چند ترابایتی را فراهم می آورد.

 

FAST Cache چگونه کار می کند ؟

داده ها روی یک LUN که درگیر دسترسی های خواندن و نوشتن می شوند به FAST Cache، ارائه می شوند. بر اساس تعداد و نوع دسترسی ( خواندن و/یا نوشتن ) FAST Cache درگیر خواهد شد. بیاد داشته باشید که اگر I/O ورودی از لایه Extreme Performance مربوط به FAST VP خارج شود، Fast Cache در این مورد هیچ دخالتی انجام نخواهد داد.

 

مراحل کار بدین شکل است. در ابتدا فرض کنید Fast Cache خالی است :

  1. هنگامی که اولین I/O توسط نرم افزار فرستاده شد، FAST Cache Policy Engine به Memory Map در Fast Cache، نگاه می کند.  در این مرحله با توجه به فرض، Memory Map نیز خالی است، پس در نتیجه به Chunk ها از روی هارد دیسک های LUN دسترسی پیدا می کند. به این فرآیند Fast Cache Miss گفته می شود. EMC ادعا می کند که که این فرآیند بررسی Memory Map برای هر دسترسی، تاثیر بسیار ناچیزی بروی عملکرد Storage دارد.
  2. اگر نرم افزار بطور مدام دسترسی به Chunk را نیاز داشته باشد، Policy Engine آن Chunk را از هارد دیسک ها بروی FAST Cache کپی می کند. این عملیات را Promotion می نامند و به این دوره زمانی Warm UP Period برای FAST Cache گویند.
  3. زمانی که نرم افزار مجددا به Chunk نیاز داشت، Policy Engine بررسی می کند که آیا Chunk در FAST Cache وجود دارد یا خیر ( بر اساس Memory Map ). به این فرآیند FAST Cache Hit گویند. بدلیل اینکه نرم افزار از روی دیسک های Flash به داده دسترسی می یابد، نرم افزار صاحب Response Times بسیار کوچک بهمراه IOPS بسیار بالا می شود.

 

  • Reads

I/O ورودی از نرم افزارها و هاستها با FAST Cache Memory Map مقایسه می شوند. اگر درMemory MAP موجود Chunk درخواستی وجود داشت، Chunk از روی FAST Cache خوانده می شود و در اختیار درخواست کننده قرار می گیر. در صورت عدم وجود Chunk درخواست I/O ورودی مسیری عادی خود را در پیش می گیرد و Chunk را از روی هارد دیسک های مربوط به LUN می خواند.

 

  • Writes

اگر I/O ورودی، درخواستی مبتنی بر نوشتن Chunk بروی FAST Cache باشد، در صورتی که Write Cache برای LUN غیر فعال نباشد، DRAM Cache خود را با یک Write جدید بروز رسانی می کند، و Acknowledgment را برای هاست ارسال می کند. بیاد داشته باشید که داده های شما مستقیما بروی FAST Cache نوشته نمی شود بلکه در ابتدا بروی DRAM Cache نوشته می شود و زمانی که نیار است از DRAM Cache خارج شود بروی FAST Cache نوشته می شود.

 

Write-Back Operation :

Write-Back Operation در واقع وضعیتی است که در آن داده ها از FAST Cache بروی هارد دیسک های Back End منتقل می شوند. این فرآیند به هنگامی رخ می دهد که ظرفیت FAST Cache پر شده و دیگر فضای خالی برای فرآیند FAST Cache وجود ندارد. پس داده ها را به هارد دیسکها منتقل می نماید تا FAST Cache دارای فضای خالی شود.

۰-۲۵۳۲۴۱۶.VMware vCenter Operations Manager Foundation 5.8.5

مدیریت ظرفیت و توان مورد نیاز ماشین‌های مجازی را می‌توان با استفاده از نرم افزار Vmware vCenter CapacityIQ تسهیل نمود. این نرم افزار که از اواسط سال ۲۰۱۲ در بسته vCenter Operations Managerعرضه می‌شود این امکان را فراهم می‌سازد تا منابع مورد نیاز و قابل دسترس در زمان مناسب به ماشین‌های مجازی، resource pool ها و دیتاسنترها اختصاص یابد. شما می‌توانید مشکلات احتمالی در آینده را پیش بینی کنید، نیاز به تغییر در منابع و همچنین استفاده از منابع آزاد را به طور پویا مدل سازی و در کنترل بگیرید.

فایل ها همانند همیشه از VMware مستقیماً تهیه شده و با نام اصلی و بدون هیچ دخل و تصرفی در اختیارشما قرار میگیرد.

 

Link 1 : VMware-vcops-5.8.5.0-2532416-vapp.ova

Link 2 : VMware-vcops-5.8.5.0-2532416-vapp.ova

Link 3 سرور ایران : VMware-vcops-5.8.5.0-2532416-vapp.ova

File size: ۱.۴۱ GB

Link 1 : VMware-vcops-SP3-2191616.pak

Link 2 : VMware-vcops-SP3-2191616.pak

Link 3 سرور ایران : VMware-vcops-SP3-2191616.pak

File size: ۳.۲۰ GB

Link 1 : VMware-vcops-5.8.5-2532416.pak

Link 2 : VMware-vcops-5.8.5-2532416.pak

Link 3 سرور ایران : VMware-vcops-5.8.5-2532416.pak

File size: ۴۸۳ MB

Password: www.vcloudtip.com