حساب کاربری

نحوه پیکربندی Pool در خانواده Dell Unity - مقدمه‌ای بر Data Efficiency

دسته بندی:
ذخیره‌سازی و مدیریت داده
تاریخ به روز رسانی:
1404/11/29 ساعت 14:08



مقدمه ای بر Data Efficiency

Data Efficiency در خانواده Dell Unity به مجموعه ای از قابلیت ها گفته می شود که کمک می کند عملکرد درایوها و بهره وری فضای Pool هم زمان مدیریت شود. در همین بخش، مشخص می شود چه زمانی باید روی FAST تمرکز کرد و چه زمانی سراغ کاهش مصرف فضا رفت. نتیجه عملی این مقدمه این است که انتخاب ها برای پیکربندی Pool، هدفمندتر و قابل پیش بینی تر می شوند.

قابلیت های مطرح شده در این بخش:

  • FAST Cache
    • این قابلیت برای افزایش کارایی I/O طراحی شده و با استفاده از Flash به عنوان cache، واکنش سیستم را سریع تر می کند.
    • وقتی بار کاری تغییر می کند، رفتار cache هم با آن هماهنگ می شود و به صورت پویا پاسخ می دهد.
    • در عمل، برای سناریوهای burst و دسترسی های پرتکرار بسیار اثرگذار است.
  • FAST VP
    • FAST VP داده ها را بین Tier های مختلف جابه جا می کند تا داده های مهم تر روی درایوهای سریع تر قرار بگیرند.
    • این جابه جایی بر اساس policy و فعالیت I/O انجام می شود و نگاه آن بیشتر Tiering محور است.
    • برای تعادل بین Performance و Capacity در Pool کاربرد کلیدی دارد.
  • Automatic Snapshot Deletion
    • این قابلیت یک مکانیزم مدیریت فضا است تا تعداد snapshotها در یک Pool کنترل شود.
    • وقتی مصرف Pool یا مصرف snapshotها به threshold برسد، حذف خودکار فعال می شود.
    • ترتیب حذف هم مشخص است تا ابتدا موارد منقضی شده پاک شوند.
  • Data Reduction
    • یک سوئیچ واحد است که compression و deduplication را در سطح LUN و File System کنترل می کند.
    • روی write های جدید اعمال می شود و داده های غیرقابل کاهش، بدون compression نوشته می شوند.
    • برای storage resourceهای thin در دسترس است و رفتار آن در برنامه ریزی Pool مهم است.
  • Advanced Deduplication
    • قابلیت تکمیلی برای deduplicate عمیق تر و پویا است و تنها وقتی فعال می شود که Data Reduction روشن باشد.
    • هدف آن کاهش فضای user data با نگه داشتن تعداد کمی کپی از بلاک های یکسان است.
    • محدودیت های سخت افزاری و Pool-specific دارد و باید دقیق رعایت شود.

بهینه سازی عملکرد درایو با FAST Cache و FAST VP

(فقط در پیاده سازی های فیزیکی پشتیبانی شده)

در این بخش، تمرکز روی این است که Pool چگونه می تواند از Flash و Tiering برای بهبود رفتار I/O استفاده کند. FAST Cache و FAST VP هر دو به بهبود performance کمک می کنند، اما مسیرشان متفاوت است. شناخت تفاوت آن ها باعث می شود انتخاب بین cache و tiering بر اساس نوع workload انجام شود. این نگاه، از تصمیم های اشتباه در تخصیص Flash جلوگیری می کند.

 معرفی FAST (Fully Automated Storage Tiering) Suite

FAST Suite مجموعه ای از قابلیت هاست که برای بهینه سازی عملکرد و جابه جایی هوشمند داده طراحی شده است. در این مجموعه، یک بخش نقش cache پرسرعت را بازی می کند و بخش دیگر، Tiering را در سطح دقیق تر مدیریت می کند. همین تفکیک باعث می شود Pool بتواند هم پاسخ سریع داشته باشد و هم توزیع داده منطقی بماند.

FAST Suite شامل موارد زیر است:

  • استفاده از SAS Flash 2 به عنوان Read/Write Cache اضافی (FAST Cache)
    • SAS Flash 2 به عنوان یک cache اضافی خواندن/نوشتن به storage system اضافه می شود.
    • این cache برای بالا بردن سرعت دسترسی به داده های پرتکرار به کار می رود.
    • در نتیجه، بخشی از فشار I/O از روی HDD برداشته می شود.
  • Tier کردن پویا داده ها بین انواع درایوها (FAST VP)
    • FAST VP داده ها را بین انواع مختلف درایوها به صورت پویا Tier می کند.
    • جابه جایی داده ها بر اساس policy و میزان فعالیت I/O انجام می شود.
    • نکته مهم این است که FAST VP از همه انواع درایوهای پشتیبانی شده به جز SAS Flash 4 استفاده می کند.

FAST Cache

FAST Cache برای سناریوهایی طراحی شده که دسترسی های پرتکرار و نوسانی وجود دارد. این قابلیت با cache کردن داده در سطح کوچک تر، سرعت پاسخ گویی را بهبود می دهد. همچنین به صورت پیوسته با workload هماهنگ می شود و رفتار cache را با تغییر بار تنظیم می کند.

  • استفاده از SAS Flash 2 به عنوان Cache خواندن/نوشتن
    • این قابلیت امکان استفاده از SAS Flash 2 را به عنوان cache اضافی خواندن/نوشتن فراهم می کند.
    • هدف، افزایش performance کلی storage system بدون تغییر مستقیم در Tierهای اصلی است.
    • در محیط هایی با I/O متغیر، این الگو معمولاً نتیجه ملموس تری ایجاد می کند.
  • Cache کردن بلوک های 64-KB
    • FAST Cache داده را در بلوک های 64KB cache می کند تا پاسخ گویی سریع تر شود.
    • این اندازه بلوک برای افزایش کارایی cache در دسترسی های پرتعداد کاربرد دارد.
    • در نتیجه، عملیات پرتکرار با تأخیر کمتر پاسخ می گیرد.
  • کپی داده های پرتکرار از HDD به Flash Drive
    • وقتی داده به صورت مکرر خوانده یا نوشته شود، از HDD به Flash کپی می شود.
    • این رفتار باعث می شود داده های پرمصرف در مسیر سریع تری سرویس دهی شوند.
    • اثر آن بیشتر زمانی دیده می شود که workload حالت burst داشته باشد.
  • سازگاری پیوسته با تغییرات Workload
    • FAST Cache به صورت مداوم با تغییر workload سازگار می شود.
    • این یعنی رفتار cache محدود به یک بازه زمانی ثابت نیست و با تغییر الگوها تنظیم می شود.
    • همین ویژگی، آن را برای تغییرات لحظه ای و کوتاه مدت مناسب می کند.

FAST VP

FAST VP به جای cache کردن، داده را بین Tierهای مختلف جابه جا می کند تا جای درست داده در Pool حفظ شود. سطح تصمیم گیری آن در مقیاس بزرگ تر است و به policy و فعالیت I/O تکیه دارد. این رویکرد کمک می کند داده های “hotter” در Tierهای سریع تر قرار بگیرند و داده های “colder” در Tierهای ظرفیت محور.

  • استفاده از Pool برای Tiering در سطح Sub-LUN و File System
    • FAST VP برای ارائه Tiering در سطح sub-LUN و file system از pool استفاده می کند.
    • داده ها بر اساس FAST VP tiering policy به Tier مناسب منتقل می شوند.
    • این سطح از Tiering، کنترل دقیق تری نسبت به جابه جایی های کلی فراهم می کند.
  • جابه جایی بلوک های 256-MB بر اساس:
    • FAST VP داده را در chunkهای 256MB جابه جا می کند.
    • این جابه جایی به policy و میزان فعالیت I/O وابسته است.
    • نتیجه آن، توزیع منطقی داده در Tierهای مختلف Pool است.
    • FAST VP Tiering Policy
      • policy مشخص می کند داده باید به کدام Tier منتقل شود.
      • تصمیم گیری بر اساس قواعد تعریف شده انجام می شود، نه حدس و گمان.
      • این policy ستون اصلی رفتار Tiering در FAST VP است.
    • فعالیت I/O
      • شدت و الگوی I/O روی تصمیم جابه جایی اثر مستقیم دارد.
      • داده های فعال تر، شانس بالاتری برای رفتن به performance drive دارند.
      • داده های کم فعالیت تر به سمت capacity drive حرکت می کنند.
  • انتقال:
    • هدف اصلی، تفکیک داده های “hotter” و “colder” در سطح Tier است.
    • این تفکیک باعث استفاده بهتر از منابع سریع و منابع ظرفیت محور می شود.
    • در نتیجه، Pool هم از نظر performance و هم از نظر بهره وری منطقی تر عمل می کند.
    • داده های Hot به Performance Drive
      • داده های داغ تر به performance drive منتقل می شوند تا I/O سریع تر پاسخ بگیرد.
      • این انتقال بر اساس policy و فعالیت انجام می شود، نه به صورت دستی.
      • نتیجه، کاهش تأخیر روی داده های پرترافیک است.
    • داده های Cold به Capacity Drive
      • داده های سردتر به capacity drive منتقل می شوند تا منابع سریع اشغال نشوند.
      • این جابه جایی به کنترل هزینه و بهبود بهره وری درایوها کمک می کند.
      • برای نگه داری داده های کم مصرف، این Tier مناسب تر است.
  • استفاده از فرآیند Data Relocation برای تنظیم دوره ای Tiering:
    • FAST VP یک فرآیند data relocation دارد که Tiering را به صورت دوره ای تنظیم می کند.
    • زمان بندی این فرآیند قابل تنظیم است و می تواند سناریوهای مختلف را پوشش دهد.
    • همین انعطاف باعث می شود رفتار Tiering قابل کنترل باقی بماند.
    • اجرای زمان بندی شده
      • امکان اجرای relocation به صورت روزی یک بار وجود دارد.
      • این مدل برای محیط هایی که تغییرات workload قابل پیش بینی تر است مناسب است.
      • هدف، تنظیم Tiering در بازه های مشخص و پایدار است.
    • اجرای مداوم در طول روز
      • relocation می تواند به صورت پیوسته در طول روز انجام شود.
      • این حالت برای workloadهای متغیرتر کاربرد بیشتری دارد.
      • نتیجه، همگام سازی سریع تر Tiering با تغییرات I/O است.

 مقایسه FAST Cache و FAST VP

این مقایسه کمک می کند هنگام طراحی یا اصلاح Pool، نقش هر قابلیت به درستی انتخاب شود. FAST Cache بیشتر روی افزایش سرعت پاسخ در لحظه تمرکز دارد. FAST VP روی جای گیری درست داده در Tierها و تنظیم دوره ای تکیه می کند. نتیجه این بخش، روشن شدن مسیر انتخاب بین cache و tiering است.

  • FAST Cache:
    • Cache در سطح 64-KB انجام می دهد و برای افزایش کارایی cache طراحی شده است.
    • وقتی داده به صورت مکرر دسترسی شود، از HDD به Flash کپی می شود.
    • به صورت پیوسته با تغییرات workload سازگار می شود.
  • FAST VP
    • داده را در سطح 256-MB بر اساس policy و فعالیت I/O جابه جا می کند.
    • Tiering در سطح sub-LUN و file system و با تکیه بر pool انجام می شود.
    • با فرآیند data relocation، تنظیم Tiering به صورت دوره ای یا مداوم اجرا می شود.

ملاحظات Interoperability

این بخش روی نحوه هم زیستی FAST Cache و FAST VP در یک storage system تمرکز دارد. استفاده هم زمان می تواند هم performance را بالا ببرد و هم TCO را بهبود دهد. ترتیب پیشنهادی استفاده از Flash، از اتلاف منابع جلوگیری می کند. همچنین رفتار Tier-aware در FAST Cache مانع کپی های غیرضروری می شود.

  • امکان استفاده هم زمان FAST Cache و FAST VP
    • FAST Cache و FAST VP می توانند هم زمان فعال باشند.
    • هدف این هم زیستی، دریافت عملکرد بالاتر و بهبود TCO است.
    • طراحی درست باعث می شود منابع Flash هدفمند مصرف شوند.
  • توصیه:
    • ترتیب پیشنهادی، ابتدا بهره گیری از Flash موجود برای cache است.
    • سپس در صورت نیاز، افزایش Flash در Tierهای pool برای استفاده FAST VP مطرح می شود.
    • این رویکرد به همه منابع storage در سیستم سود می رساند.
    • استفاده اولیه از SAS Flash 2 موجود برای FAST Cache
      • توصیه می شود ابتدا SAS Flash 2 موجود برای FAST Cache استفاده شود.
      • این کار به جای محدود شدن به یک Tier، به کل storage system کمک می کند.
      • نتیجه، بهبود سریع تر رفتار I/O در سطح سیستم است.
    • در صورت نیاز به عملکرد بیشتر، افزودن Flash به Tierهای Pool برای استفاده توسط FAST VP
      • اگر عملکرد بیشتری لازم باشد، Flash اضافی به Tierهای pool اضافه می شود.
      • این Flash سپس توسط FAST VP برای Tiering استفاده خواهد شد.
      • این مرحله، بعد از بهره برداری از FAST Cache پیشنهاد می شود.

سناریوی تعداد محدود SAS Flash 2

این سناریو زمانی مطرح می شود که تعداد Flash محدود است و باید بهترین استفاده از آن انجام شود. راهکار پیشنهادی شامل ساخت FAST Cache و سپس اعمال FAST VP روی poolهای ساده تر است. این ترکیب کمک می کند هم burstها بهتر پاسخ بگیرند و هم Tiering کلی برقرار شود.

  • ایجاد FAST Cache با درایوهای موجود
    • با SAS Flash 2 محدود هم می توان FAST Cache ایجاد کرد.
    • این کار داده های پرتکرار را سریع تر سرویس می دهد.
    • نتیجه، بهبود عملکرد در بازه های پرترافیک است.
  • اعمال FAST VP روی:

    • FAST VP می تواند روی pool اعمال شود تا جابه جایی داده بین Tierها انجام گیرد.
    • در سناریوی Flash محدود، تمرکز روی poolهای تک سطحی یا دو سطحی است.
    • این کار تعادل بین performance و capacity را نگه می دارد.
    • Pool تک سطحی
      • FAST VP می تواند روی pool تک سطحی هم اعمال شود.
      • در این حالت، Tiering در چارچوب همان سطح و سیاست های تعریف شده مدیریت می شود.
      • این گزینه برای شروع ساده تر و کنترل پذیرتر است.
    • Pool دو سطحی (SAS و NL-SAS)
      • pool دو سطحی شامل SAS و NL-SAS است و برای تفکیک performance و capacity مناسب است.
      • FAST VP می تواند داده های hotter را به SAS و colder را به NL-SAS منتقل کند.
      • این مدل برای بهره وری درایوها کاربرد بیشتری دارد.

جلوگیری از مصرف بیهوده منابع Flash

این قسمت دقیقاً روی جلوگیری از کپی های غیرلازم تمرکز دارد. FAST Cache از Tier آگاه است و با FAST VP همکاری می کند تا Flash به صورت غیرهدفمند مصرف نشود. وقتی داده به Tier بسیار سریع منتقل شود، دیگر نیاز به کپی همان داده در cache وجود ندارد. این منطق، مصرف منابع را منطقی نگه می دارد.

  • FAST Cache از Tier آگاه است
    • FAST Cache نسبت به storage tier آگاهی دارد.
    • همین آگاهی باعث می شود با FAST VP هم راستا عمل کند.
    • نتیجه، جلوگیری از مصرف بی دلیل منابع storage system است.
  • اگر FAST VP یک Chunk را به Extreme Performance Tier منتقل کند:
    • وقتی chunk به Extreme Performance Tier برود، سیستم آن را به FAST Cache کپی نمی کند.
    • حتی اگر معیار ارتقاء FAST Cache برقرار باشد، این کپی انجام نمی شود.
    • هدف، جلوگیری از کپی Flash به Flash و هدررفت منابع است.

Automatic Snapshot Deletion

Automatic snapshot deletion یک قابلیت مدیریت فضا برای کنترل تعداد snapshotها در pool است. این قابلیت با thresholdهایی که تعریف می شود فعال شده و حذف را مرحله به مرحله پیش می برد. ترتیب حذف به گونه ای است که ابتدا snapshotهای منقضی شده حذف شوند. برخی snapshotها هم از این چرخه حذف مستثنی هستند و باید در طراحی لحاظ شوند.

 شرایط فعال سازی

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

  • مصرف کل Pool به Threshold تعیین شده برسد
    • اگر مصرف کلی pool به threshold بالا برسد، حذف خودکار فعال می شود.
    • سیستم حذف را ادامه می دهد تا مصرف به حد تعیین شده برگردد.
    • این مکانیزم برای جلوگیری از پر شدن pool کاربرد دارد.
  • یا مصرف Snapshotها در Pool به Threshold برسد
    • اگر مصرف pool توسط snapshotها به threshold برسد، همان روند فعال می شود.
    • تمرکز این حالت، کنترل رشد snapshotها و حفظ فضای pool است.
    • حذف تا رسیدن به threshold ادامه پیدا می کند.

 ترتیب حذف Snapshotها

ترتیب حذف در این قابلیت دقیق است و به صورت مرحله ای انجام می شود. ابتدا موارد منقضی شده حذف می شوند تا کم ریسک ترین حذف ها انجام گیرد. اگر هنوز به threshold نرسد، حذف سراغ snapshotهای قدیمی ترِ detached می رود. این ترتیب کمک می کند حذف، کنترل شده و قابل پیش بینی باشد.

  • حذف Snapshotهای منقضی شده
    • ابتدا snapshotهای expired حذف می شوند.
    • این مرحله سریع تر به آزادسازی فضا کمک می کند.
    • همچنین از حذف های حساس تر جلوگیری می کند.
  • حذف قدیمی ترین Snapshotهای Detached (در صورت فعال بودن Automatic Deletion)
    • اگر پس از حذف expiredها هنوز threshold تأمین نشود، حذف ادامه می یابد.
    • سیستم قدیمی ترین snapshotهای detached را حذف می کند، مشروط به فعال بودن automatic deletion.
    • این کار تا رسیدن مصرف pool به threshold تعیین شده ادامه پیدا می کند.

 موارد مستثنی از حذف خودکار

برخی snapshotها به دلایل عملیاتی نباید خودکار حذف شوند. این استثناها برای حفظ یکپارچگی سرویس ها و قابلیت هایی مثل replication ضروری است. در برنامه ریزی snapshotها در pool، این موارد باید از ابتدا دیده شوند. نادیده گرفتن این استثناها معمولاً مدیریت فضا را پیچیده تر می کند.

  • Snapshotهای متصل به Host
    • snapshotهای متصل به host حذف خودکار نمی شوند.
    • این محدودیت برای جلوگیری از اختلال در دسترسی hostها اعمال می شود.
    • بنابراین در محاسبه فضای pool باید در نظر گرفته شوند.
  • Snapshotهای Consistency Group
    • گروه های snapshot متصل در consistency group مستثنی هستند.
    • دلیل آن، حفظ سازگاری و هماهنگی snapshotها در سطح گروه است.
    • حذف خودکار روی این دسته اعمال نمی شود.
  • System Snapshotهای Replication
    • system snapshotهایی که برای replication استفاده می شوند حذف نمی شوند.
    • این محدودیت برای محافظت از جریان replication و داده های وابسته است.
    • در طراحی فضای pool، این بخش باید رزرو ذهنی داشته باشد.

گزینه های تنظیم

گزینه های تنظیم، مسیر حذف را مشخص می کنند و تعیین می کنند حذف بر اساس pool یا زمان انقضا انجام شود. امکان تنظیم هر snapshot هم وجود دارد تا حذف هنگام انقضا یا هنگام رسیدن pool به threshold اجرا شود. این انعطاف باعث می شود سیاست نگه داری snapshotها دقیق تر شود. در نتیجه، کنترل فضا در pool ساده تر می شود.

  • Pool (حذف هنگام رسیدن Pool به Threshold)
    • این گزینه برای snapshotهای storage resource و pool اعمال می شود.
    • وقتی pool به threshold برسد، سیستم snapshot را حذف می کند.
    • رفتار حذف تا بازگشت مصرف به سطح تعیین شده ادامه دارد.
  • Expiration Time (حذف در زمان انقضا)
    • این گزینه برای snapshotهای storage resource استفاده می شود.
    • expiration time زمان انقضای snapshot را مشخص می کند.
    • با رسیدن به این زمان، snapshot برای حذف در نظر گرفته می شود.

NOTE

در صورت فعال بودن automatic snapshot deletion برای یک snapshot، آن snapshot نباید به عنوان source snapshot برای ایجاد یا refresh یک thin clone استفاده شود. این محدودیت یک نکته عملیاتی مهم است و در طراحی چرخه snapshot و clone باید از ابتدا لحاظ شود. رعایت این مورد از خطاهای غیرمنتظره در مراحل بعدی جلوگیری می کند.

Data Reduction

Data Reduction یک کنترل واحد است که فشرده سازی و deduplication را در سطح LUN و file system مدیریت می کند. این قابلیت با هدف صرفه جویی فضا طراحی شده و روی writeهای جدید اعمال می شود. اگر داده قابل کاهش نباشد، بدون compression نوشته می شود. برای پوشش داده های قبلی هم مسیر مشخصی تعریف شده است.

Data Reduction شامل موارد زیر است:

  • Deduplicate کردن بلوک هایی با الگوهای داده داخلی (Zero Detection)
    • بخشی از صرفه جویی فضا با شناسایی الگوهای داخلی مثل zero detection انجام می شود.
    • این deduplication در چارچوب Data Reduction تعریف شده است.
    • نتیجه، کاهش مصرف فضا بدون تغییر در ماهیت داده است.
  • Compression
    • فشرده سازی بخش دیگر کاهش مصرف فضا را تشکیل می دهد.
    • روی writeهای جدید اعمال می شود و داده های غیرقابل فشرده سازی شناسایی می شوند.
    • این داده ها بدون compression نوشته می شوند تا رفتار سیستم پایدار بماند.

Storage Resourceهای پشتیبانی شده

Data Reduction برای مجموعه مشخصی از storage resourceها در دسترس است و تمرکز اصلی روی thin است. این موضوع در زمان طراحی pool و تخصیص resource اهمیت دارد. همچنین برای thin file system یک شرط نسخه ای مشخص شده است. رعایت این شرط از ناسازگاری های عملیاتی جلوگیری می کند.

  • Thin LUN
    • Data Reduction برای thin LUN در دسترس است.
    • کنترل آن در سطح LUN انجام می شود و روی writeهای جدید اثر می گذارد.
    • در نتیجه، رفتار فضای مصرفی LUN قابل بهینه سازی است.
  • Thin File System
    • thin file system هم می تواند از Data Reduction استفاده کند.
    • شرط مهم این است که این فایل سیستم باید با نسخه مشخصی ساخته شده باشد.
    • در غیر این صورت امکان استفاده از قابلیت فراهم نیست.
  • Thin NFS Datastore
    • برای thin NFS datastore هم Data Reduction قابل استفاده است.
    • این گزینه در سناریوهای datastore محور، روی بهره وری فضا اثر می گذارد.
    • اعمال آن همچنان روی writeهای جدید انجام می شود.
  • VMFS Datastore
    • VMFS datastore نیز در فهرست موارد پشتیبانی شده قرار دارد.
    • این مورد به خصوص در محیط هایی که datastore نقش اصلی دارد اهمیت پیدا می کند.
    • مدیریت کاهش فضا در همین سطح انجام می شود.

شرط:
Thin File System باید روی Unity با نسخه OE 4.2.x یا جدیدتر ایجاد شده باشد. این شرط برای فعال شدن قابلیت در سطح file system ضروری است و باید قبل از تصمیم گیری لحاظ شود.

 نحوه اعمال

Data Reduction به صورت مستقیم روی writeهای جدید اعمال می شود و رفتار آن در برابر داده های غیرقابل کاهش مشخص است. داده های قبلی پس از فعال سازی، خودکار تحت این سیاست قرار نمی گیرند. این نکته در زمان برنامه ریزی تغییرات روی pool و resource اهمیت دارد. مسیر اعمال روی داده های موجود هم صریح و عملیاتی تعریف شده است.

  • اعمال فقط روی Writeهای جدید
    • Data Reduction روی همه writeهای جدید اعمال می شود.
    • داده های غیرقابل deduplicate یا compress شناسایی می شوند.
    • این داده ها بدون compression نوشته می شوند.
  • داده های موجود قبلی تحت Data Reduction قرار نمی گیرند
    • داده های موجود روی LUN بعد از فعال سازی، خودکار شامل Data Reduction نمی شوند.
    • بنابراین صرفاً روشن کردن قابلیت، گذشته را تغییر نمی دهد.
    • برای داده های قبلی باید مسیر دیگری اجرا شود.

 اعمال روی داده های موجود

برای پوشش داده های قبلی، راهکار مشخص شده و نیاز به جابه جایی داده دارد. این کار با قابلیت LUN Move انجام می شود تا داده به مقصدی منتقل شود که Data Reduction روی آن فعال است. این روش، یک مسیر کنترل شده برای اعمال سیاست کاهش فضا ایجاد می کند. نتیجه، یکپارچگی رفتار کاهش فضا بین داده های جدید و قدیمی است.

  • استفاده از قابلیت LUN Move
    • برای اعمال Data Reduction روی داده های موجود باید از LUN Move استفاده شود.
    • این قابلیت مسیر انتقال داده را فراهم می کند.
    • در نتیجه، داده ها وارد چرخه Data Reduction می شوند.
  • انتقال داده به LUN مقصد با Data Reduction فعال
    • داده های LUN به یک LUN مقصد منتقل می شوند که Data Reduction فعال دارد.
    • این انتقال باعث می شود داده های قبلی هم تحت همان سیاست قرار بگیرند.
    • اجرای درست این مرحله برای همسان سازی سیاست ها ضروری است.

Advanced Deduplication

 پیش نیاز

Advanced Deduplication فقط زمانی قابل فعال سازی است که Data Reduction از قبل فعال شده باشد. این وابستگی مهم است و باید قبل از هر تصمیم گیری در سطح resource و pool بررسی شود. فعال کردن بدون پیش نیاز، قابل انجام نیست. همین پیش نیاز، ترتیب اجرای تنظیمات را مشخص می کند.

  • فعال بودن Data Reduction
    • Advanced Deduplication تنها در صورتی فعال می شود که Data Reduction روشن باشد.
    • این یعنی ابتدا باید سوئیچ اصلی کاهش داده فعال شود.
    • سپس گزینه تکمیلی برای deduplication عمیق تر قابل استفاده است.

سیستم های پشتیبانی شده

پشتیبانی Advanced Deduplication به مدل سیستم و نوع pool وابسته است. این موضوع در زمان انتخاب یا طراحی pool اهمیت بسیار زیادی دارد. برخی مدل ها از dynamic یا traditional pool پشتیبانی می کنند و برخی صرفاً در چارچوب dynamic pool تعریف شده اند. همچنین All-Flash و Hybrid Flash pool در مدل های مشخصی پشتیبانی می شوند.

  • Dynamic یا Traditional Pool در:
    • Unity 380F
      • این مدل در گروه سیستم های پشتیبانی شده قرار دارد.
      • Advanced Deduplication روی dynamic یا traditional pool قابل استفاده است.
      • فعال سازی همچنان وابسته به Data Reduction است.
    • 480F
      • در همین دسته قرار می گیرد و از dynamic یا traditional pool پشتیبانی می کند.
      • قابلیت Advanced Deduplication در چارچوب این poolها ارائه می شود.
      • رعایت پیش نیازها برای فعال سازی الزامی است.
    • 680F
      • پشتیبانی برای dynamic یا traditional pool در این مدل هم اعلام شده است.
      • این موضوع انتخاب نوع pool را در طراحی مؤثر می کند.
      • فعال سازی بدون Data Reduction ممکن نیست.
    • 880F
      • در فهرست پشتیبانی Advanced Deduplication قرار دارد.
      • نوع pool می تواند dynamic یا traditional باشد.
      • سیاست های فعال سازی مشابه سایر مدل های این دسته است.
  • Dynamic Pool در:
  • 450F
    • در این مدل، پشتیبانی صرفاً برای dynamic pool ذکر شده است.
    • بنابراین نوع pool باید مطابق همین محدودیت انتخاب شود.
    • سپس با فعال بودن Data Reduction، قابلیت قابل فعال سازی است.
  • 550F
    • این مدل هم در گروه dynamic pool قرار دارد.
    • طراحی pool باید با این محدودیت هماهنگ باشد.
    • بعد از آن، Advanced Deduplication قابل استفاده می شود.
  • 650F
    • پشتیبانی Advanced Deduplication برای dynamic pool در این مدل ذکر شده است.
    • انتخاب pool و resource باید دقیقاً مطابق همین چارچوب باشد.
    • پیش نیاز Data Reduction همچنان برقرار است.
  • All-Flash Pool و Hybrid Flash Pool در:
  • Unity Hybrid 380
  • All-Flash و Hybrid Flash pool در این سیستم ها قابل استفاده هستند.
  • LUN، file system یا datastore می توانند Data Reduction روشن یا خاموش داشته باشند.
  • اما برای Advanced Deduplication، پیش نیازها باید رعایت شود.
  • 480
    • این مدل هم در دسته سیستم هایی است که All-Flash و Hybrid Flash pool را پوشش می دهد.
    • امکان ترکیب resourceهای دارای Data Reduction و بدون آن وجود دارد.
    • فعال سازی Advanced Deduplication مطابق قواعد ذکرشده انجام می شود.
  • 680
    • All-Flash و Hybrid Flash pool برای این مدل هم ذکر شده است.
    • این موضوع روی طراحی pool و تخصیص resource اثر مستقیم دارد.
    • شرط های Hybrid pool همچنان باید رعایت شود.
  • 880
    • این مدل نیز در فهرست پشتیبانی All-Flash و Hybrid Flash pool آمده است.
    • امکان وجود resourceهای مختلف در pool بیان شده است.
    • اما قواعد فعال سازی Advanced Deduplication ثابت است.

 محدودیت Hybrid Pool

در hybrid pool یک محدودیت کلیدی وجود دارد که مستقیماً به درصد Flash Drive در pool مربوط است. اگر Data Reduction و Advanced Deduplication برای یک storage resource فعال باشد یا حتی قبلاً فعال بوده و سپس غیرفعال شده باشد، درصد Flash باید حداقل مقدار مشخصی باشد. عدم رعایت این شرط باعث خطا می شود. بنابراین در طراحی hybrid pool، ترکیب Flash و HDD باید از ابتدا کنترل شود.

  • درصد Flash Drive باید حداقل 10٪ باشد
  • در hybrid pool، درصد Flash driveهای موجود باید حداقل 10٪ یا بیشتر باشد.
  • این شرط در سناریوهای فعال بودن یا سابقه فعال بودن قابلیت ها مطرح شده است.
  • رعایت آن برای جلوگیری از خطا ضروری است.
  • در غیر این صورت خطا رخ خواهد داد
  • اگر حداقل درصد Flash رعایت نشود، سیستم با خطا مواجه می شود.
  • این خطا مستقیماً از محدودیت تعریف شده برای hybrid pool ناشی می شود.
  • بنابراین طراحی pool باید با این الزام سازگار باشد.

جمع بندی این بخش

  • انتخاب و پیاده سازی FAST Cache و FAST VP
  • FAST Cache مسیر بهبود سریع پاسخ گویی با cache در سطح 64KB را پوشش می دهد.
  • FAST VP با relocation در سطح 256MB و policy محور، جای گیری داده را در Tierها تنظیم می کند.
  • ترکیب این دو، هم برای burst و هم برای توزیع بلندمدت داده کاربرد دارد.
  • تنظیم Automatic Snapshot Deletion
  • حذف خودکار با رسیدن مصرف pool یا snapshotها به threshold فعال می شود.
  • ترتیب حذف از expiredها شروع می شود و سپس سراغ قدیمی ترین detachedها می رود.
  • استثناها مثل host-attached، consistency group و replication باید از ابتدا دیده شوند.
  • فعال سازی Data Reduction
  • Data Reduction با zero detection و compression فضای مصرفی را کاهش می دهد.
  • روی writeهای جدید اعمال می شود و داده های قبلی را خودکار پوشش نمی دهد.
  • برای داده های موجود، مسیر LUN Move به مقصد دارای Data Reduction مطرح است.
  • فعال سازی Advanced Deduplication با رعایت محدودیت ها
  • فعال سازی فقط با پیش نیاز Data Reduction ممکن است.
  • پشتیبانی آن به مدل سیستم و نوع pool وابسته است و باید دقیق انتخاب شود.
  • در hybrid pool، الزام حداقل 10٪ Flash Drive یک شرط حیاتی است.

نتیجه ای که برای طراحی Pool باید همراه داشت

Data Efficiency مسیر تصمیم گیری را برای انتخاب بین cache و tiering روشن می کند و هم زمان کنترل فضای pool را جدی تر می سازد. وقتی FAST Cache و FAST VP با نگاه درست کنار هم قرار بگیرند، performance بهتر و مصرف منابع منطقی تر می شود. در سمت مدیریت فضا هم automatic snapshot deletion و Data Reduction چارچوب واضحی برای کنترل رشد داده ایجاد می کنند، و Advanced Deduplication فقط در صورتی ارزش واقعی می دهد که محدودیت های pool و درصد Flash دقیق رعایت شده باشد.

 

برای دریافت مشاوره تخصصی در این زمینه، می‌توانید از طریق صفحه «ارتباط با ما» با کارشناسان آکو در ارتباط باشید.