بایگانی ماه آذر, ۱۳۹۴

تمامی دیتا ها به طور یکسان مورد دسترسی قرار نمی گیرند. بعضی از دیتاها بصورت مداوم و بعضی دیگر به ندرت نیاز به دسترسی دارند. با توجه به معرفی و رونمایی قابلیت  FAST VP در رده های CX4، VNX و VNX2، از آن پس تولید یک Storage Pool که شامل خانواده های متفاوت هارد دیسک ها باشد، ممکن شد. سیستم تمامی LUN های شما را به قطعات کوچک ( Slice ) خرد می نماید و به هر Slice، یک درجه ( درجه دمایی ) از سطح دسترسی، اعطا می شود. به عنوان نمونه Slice هایی که مداوما مورد دسترسی قرار می گیرند را Hot Slice، و آنهایی را که به ندرت مورد دسترسی قرار می گیرند را Cold Slice می نامند. پروسه FAST VP داده های Hot را به سریعترین لایه موجود ( به عنوان مثال SSD ) انتقال می دهد. زمانی که سریعترین لایه موجود به لحاظ ظرفیت تکمیل شد، آنگاه FAST VP داده های HOT بعدی را به سریعترین لایه بعدی ( به عنوان مثال SAS ) منتقل می نماید و به همین ترتیب.  شاید این موضوع برای TCO یا همان Total cost of ownership، شما بسیار شگفت انگیز باشد، زیرا که : تمامی داده های Cold شما اکنون بروی Slice های از روی هارد دیسک های NL-SAS شما نگهداری می شود و برای نگهداشت آنها از هارد دیسک های SSD گران قیمت هزینه نمی شود و بدین گونه هزینه کلی نگهداشت داده ها به شدت کاهش می یابد، ضمن اینکه کاربر نهایی شما نیز به هیچ وجه متوجه این فرآیند نمی شود. در این فرآیند تنها یک سناریو نادر وجود دارد که ممکن است شما را به چالش بکشد و آن استفاده سنگین از داده های ارشیو شده موجود بروی لایه Cold است.

• جابجایی Slice ها توسط FAST VP

همانگونه که ذکر شد FAST VP فرآیندی است که LUN ها را به Slice هایی تبدیل می کند. در رده CX4 و نسل اول VNX، تمامی Slice ها دارای سایزی برابر با ۱ GB بودند ولیکن در VNX2 با بهره گیری از تکنولوژی MCx از Slice هایی با سایز ۲۵۶ MB بهره می برد. تجهیز شما بصورت مداوم مقدار I/O که بسوی یک Slice می رود را پایش می کند و بدین شیوه یک درجه از سطح دسترسی را برای آن Slice مشخص می نماید. در هر روز در زمان برنامه ریزی شدی خاصی Slice ها بنا به درجه حرارتشان به یکی از لایه های موجود منتقل می شوند. پس به خاطر داشته باشید که فرآیند FAST VP یک فرآیند Post Process است. FAST VP تلاش می کند تا آنجایی که امکان دارد داده ها را در ابتدا بروی سریعترین لایه نگه دارد. به عنوان نمونه اگر شما یک Storage Pool با ۱۰ TB لایه SSD و ۲۰ TB لایه SAS داشته باشید و بخواهید تنها ۵ TB داده را بروی آن نگه دارید، آنگاه Fast VP تمامی ۵ GB داده را بروی لایه SSD نگه می دارد ( البته با توجه با Policy پیش فرض ). همچنین FAST VP همیشه ۱۰% فضای هر لایه ( Tier ) را خالی نگه می دارد تا به هنگام تولید Slice برای Thin LUN ها و یا تولید یک LUN جدید، دچار چالش نشود.

حال این سناریو را متصور شوید : یک سرور و یا نرم افزار شروع به تولید حجم بالایی از I/O میکند. Slice ها به سریعترین لایه موجود تحویل می شوند، تجهیز دارای عملکرد مناسبی است و Response Time به سرور و یا نرم افزار کاملا قابل قبول است. در مابقی روزهای ماه سرور یا نرم افزار بنا به دلایلی مورد استفاده قرار نمی گیرد. داده ها شروع به سرد شدن می کنند و به Clod Slice تبدیل می شوند و آنگاه FAST VP آنها را به لایه هارد دیسک های NL-SAS منتقل می نماید. در شروع ماه آینده نرم افزار مجددا به فعالیت خود بازگشته و شروع به تولید حجم بالایی I/O می کند. در اینجا ممکن است تا حدی از این بار تحمیلی را بتوان توسط FAST Cache سریعا مدیریت نمود، اما FAST VP برای مدیریت این حجم بالا نیاز به زمان برای انجام انتقال Slice ها بین لایه ها دارد که معمولا به معنای مدت زمان حدودی، یک روز است. پس در روز اول انجام فعالیت و زمان پاسخ دهی به نرم افزار مناسب نیست و عموما به همین دلیل مدیران این گونه نرم افزارها در این موارد اظهار نارضایتی می کنند.

 برای مدیریت و حل اینگونه مسائل میتوانید Tiering Policy LUN خود را بدین گونه تنظیم نمایید : Auto – Tier

در حالت معمول این Policy بروی گزینه ” Start High Then Auto-Tier ” قرار دارد. اگر نرم افزار شما به گونه ای که در بالا ذکر شد رفتار نماید، شاید شما وسوسه شوید که با انتخاب گزینه ” Highest Tier ” از FAST VP بخواهید که تمامی Slice های داده هایتان را بروی سریعترین لایه خود نگه دارد و بدین شیوه خود را دچار چالش نکنید. اما باید به خاطر داشته باشید که به این شیوه شما Slice هایی از داده های خود را بروی این Tier نگه می دارید که ممکن است هیچ نیازی به سرعت نداشته باشند. و چالش دیگر اینکه Hot Slice های مربوط به LUN های دیگر به دلیل نبود فضا روی سریعترین Tier، به ناچار به یک Tier پایین تر ارسال می شوند. مشکل زمانی بیشتر می شود که شما دارای هر سه لایه در یک POOL هستید یعنی : SSD، SAS ، NL-SAS . هیچ راهی ( تا کنون ) برای چسباندن یک LUN بروی لایه میانی وجود ندارد و انتخاب گزینه ” Highest Tier ” در یک Pool با سه لایه بمعنای انتقال تمامی داده های LUN به هارد دیسک های SSD است که درست است که بسیار سریع هستند ولیکن بسیار هم گرانند. و این بمعنای TCO بالا می باشد.

مدتی پیش در حال بررسی تجهیز یکی از مشتریان بودم و متوجه شدم گه هر شب مقدار بسیار بزرگی از داده ها توسط FAST VP بین لایه ها منتقل می شوند. من میدانم که در هارد دیسک های مکانیکی، اصلی ترین دلیل عملکرد سرعت چرخش موتور یا همان Spindle است. با بررسی وضعیت و تعداد هارد دیسک های این مشتری متوجه شدم که با توجه به نیاز به ظرفیت بالا، مشتری عموما هارد دیسکهای خود را از نوع NL-SAS انتخاب نموده و تنها تعداد کمی هارد دیسک SAS را خریداری کرده است. یک نکته ساده ولیکن مهم را به شما پیشنهاد می کنم: ” با خرید تعداد هارد دیسک بیشتر و سریعتر، عملکرد Tier را افزایش دهید. ” لطفا گراف ذیل را بررسی نمایید :

 

 همانگونه که مشاهده می فرمایید، لایه Performance دارای Slice های زیادی به رنگ قرمز ( Hot ) ، مقداربسیار کمی به رنگ نارنجی و مقداری نیز به رنگ زرد و سبز، می باشد. لایه Capacity نیز دارای Slice هایی به رنگ قرمز، مقداری نارنجی  و قدری زرد، است. مسلما متوقع هستیم که تمامی Slice های قرمز و نارنجی بروی لایه Performane منتقل شود، ولیکن این امکان پذیر نیست چرا که فضای موجود در لایه Performance توسط Cold Slice ها ( سبز ) اشغال شده و با توجه به Policy انتخاب شده، در واقع Sile های سبز به این لایه دوخته ( Pinned ) شده است.

 نکته دیگر اینکه : حتی اگر Hot Slice های لایه Capacity نیز اجازه انتقال به لایه Performance را داشته باشند، فضای کافی برای همه آنها وجود ندارد. در لایه Performance حدود ۸۰۰۰ عدد Slice به رنگهای غیر قرمز وجود دارد در حالیکه در لایه Capacity بیش از ۱۰/۰۰۰عدد Slice نارنجی و قرمز وجود دارد. پس کماکان به شما توصیه می کنم در صورت استفاده از FAST VP ، از تعداد متناسب هارد دیسک SAS بهره ببرید.

اکنون ممکن است که شما بخواهید بدانید، که کدام LUN ها هستند که بطور نسبی، شامل Cold Slice است و مثلا آنها را به لایه Capacity روی تجهیز خود Pin نمایید. خوشبختانه برای این موضوع نیز یک گزارش دیگر وجود دارد، که LUN ها و Slice ها و دمای هر Slice را نمایش می دهد. بدین گونه شما با بررسی LUN ها و یافتن بیشترین Cold Slice ها می توانید دریابید که کدام LUN در حال به هدر دادن فضای لایه های سریع شماست و آن LUN را به لایه های کم سرعت تر خود Pin نمایید. تصویر ذیل وضعیت LUN های Pin شده را نمایش می دهد. همانگونه که مشاهده می نمایید یک LUN کاملا قرمز است. این LUN در سریعترین لایه باقی می ماند اگر حتی شما Policy مربوط به Auto Tiering را هم فعال نمایید. هر دو LUN موجود در سمت چپ تصویر دارای تعداد زیادی Cold Slice ( رنگ سبز ) هستند. در این مورد فعال نمودن گزینه Auto Tiering باعث می شود تمامی این Slice ها به لایه Capacity انتقال داده شوند و روی لایه Performance فضا برای قرار گیری Hot Slice های جدید تامین شود.

 با توجه به این نمودارها ممکن است شرایط معکوس نیز رخ دهد و با خود بگویید : ” داده های Hot ( نارنجی ) روی لایه Capacity موجود است که بایستی به لایه Performance منتقل شوند. بهتر است بعضی از Lun ها را از روی این لایه Unpin کنم تا به Hot Slice های آنها به لایه Performance مهاجرت کنند. “

 

با افزایش و اعطای فضای کافی به لایه Performance مربوط به آن Pool، این امکان را فراهم آورد که اینگونه Hot Slice ها، در اولین فرآیند انتقال، به لایه Performance منتقل گردند. بررسی های بعدی مشخص نمود که این LUN ها بخشی از محیط مورد استفاده برای تبادل داده بوده اند که بسیار نیز کند بوده اند. همچنین ذکر این نکته نیز لازم است که این LUN دارای مقدار زیادی از داده های کم مصرف ( طوسی ) نیز بوده اند. این بهترین مثال برای تشریح عملکرد FAST VP و نحوه صرفه جویی حاصل از بهره مندی از آن است. با بهره مندی از FAST VP این داده های طوسی به هارد دیسک های لایه Capacity منتقل می گردند و بدین گونه دیگر شما داده های کم مصرف خود را بروی هارد های سریع و گران خود نگه نمی دارید و هزینه کمتری را صرف خرید هارد دیسک های سریع می کنید.

• طراحی Storage Pool

در طراحی یک Storage Pool شما می توانید Pool هایی با یک، دو و یا سه Tier طراحی نمایید. در شرایطی که بار تحمیلی به Storage قابل پیش بینی و یا ثابت باشد، انتخاب یک Pool سه لایه، همیشه بهترین انتخاب است : مقدار کم هارد دیسک های SSD موجود در Pool می تواند پاسخگوی داده های کاملا Hot باشد و داده های های تقریبا بیکار نیز بروی هارد دیسک های NL-SAS قرار می گیرند و از لایه میانی با هارد دیسک های SAS جهت سرویس دهی به مابقی داده ها استفاده می کند. قطعا تایید می کنید که محیط عملیاتی با محیط آزمایشگاهی کاملا متفاوت است، پس در محیط واقعی قطعا با نوسانات زیاد WorkLoad و یا تغییر ماهیت Slice ها از داده های Hot به Clod یا بلعکس  و بصورت مداوم بین لایه های مختلف بالا و پایین شوند.

شما بایستی نسبت به خواسته های نرم افزارتان از Storage بسیار آگاه و مظلع باشید.  به عنوان نمونه اگر شما یکی از آن دسته نرم افزارهایی داشته باشید که در ماه یکبار Workload بسیار زیادی را به Storage وارد می نماید و در مابقی روزهای ماه کاملا بیکار است و استفاده از هارد دیسکهای SAS کاملا پاسخگوی نیاز نرم افزار در روزهای پرکار خود است، پیشنهاد بنده استفاده از یک Pool بدون بهره گیری از هارد دیسکهای NL-SAS است. شاید شما بخواهید با استفاده ار فوت و فنهای FAST VP و بهره مندی از Policy های متفاوت آن، بخواهید داده های خود را به سریعترین Tier خود Pin نمایید، اما اگر شما یک Pool سه لایه با استفاده از هارد دیسک های SSD داشته باشید، آنگاه LUN مربوطه تمامی ظرفیت SSD ها را به خود اختصاص می دهد و باعث کندی عملکرد دیگر LUN ها خواهد شد. متاسفانه تا کنون هیچ Policy برای لایه میانی ( Middle Tier ) وجود ندارد و تنها می توان از Policy های :

• Auto-Tier
• Highest Tier
• Lowest Tier
• No Data Movement

استفاده نمود.

این موضوع می تواند تاثیر مستقیمی در طراحی، تعداد و نوع لایه های Pool ها داشته باشد. برای مثال ممکن است یک Pool با استفاده از هارد دیسک های SAS و SSD برای پاسخگویی به Workload های بحرانی و یا پر نوسان، یک Pool با سه لایه برای مصارف عمومی و یا حتی شاید یک Pool با هارد دیسک هایی از جنس SAS و NL-SAS برای نگهداری و آرشیو داده های کم اهمیت تر. متاسفانه در زمان طراحی، شما باید در خصوص نوع و طراحی Pool ها و ظرفیت مورد نظر خود بسیار وسواس به خرج دهید، زیرا که در حال حاضر تنها راه اصلاح نمودن چیدمان هارد دیسک ها، انتقال داده های کنونی از روی Pool موجود به محل دیگر، از بین بردن Pool و تولید مجدد Pool با ساختار جدید و یا Expand نمودن Pool موجود است. ولیکن در هر حال احتیاج به تولید نسخه پشتیبان از داده ها ضروری است و وقتی از چند ترابایت داده حرف می زنیم این موضوع بسیار چالش انگیز می شود.

نکته اخلاقی که می توان از این داستان دریافت!! اینست که : اجازه بدهید که FAST VP کارش را انجام دهد! هر چقدر که شما LUN های بیشتری را به سریعترین لایه Pin نمایید، فضای پر سرعت کمتری را برای FAST VP باقی می گذارید تا FAST VP بتواند Hot Slice های خود را بروی آنها جای دهد. بدین شیوه در واقع شما به FAST VP می گویید: ” من بهتر از تو می فهم!”. همانگونه که از تصویر بالا  درمی یابید، عموما اینگونه نیست و عملکرد FAST VP بسیار بهتر و صحیح تر از انتخاب های ماست.

تضاد مابین یک طراحی با تعداد بالای LUN های Pin شده به سریعترین لایه را با طراحی با تعداد کمتر LUN های Pin شده را در تصویر زیر ببینید.

 

تقریبا هیچ Slice قرمز و یا نارنجی بروی لایه Capacity وجود ندارد و تنها یک بخش بسیار کوچک از Slice های سبز بروی لایه Performance موجود است. همچنین با مشاهده این تصویر می توان بسرعت در خصوص هارد دیسک های NL-SAS دریافت که : این هارد دیسک ها IOPS نسبتا کمی را جذب نموده اند و هنوز امکان جذب IOPS بیشتری را دارند.

بسیار خوب، نظر شما درباره FAST VP و Storage Pool ها در رده VNX چیست؟ چگونه آنها را طراحی می نمایید؟ آیا LUN های زیادی را به سریعترین لایه Pin می نمایید؟ یا اجازه می دهید که FAST VP کار خودش را انجام دهد؟ لطفا در این خصوص نظرات خود را با دوستان به اشترک گذارید.