بایگانی سال 1394

مکان شما: / / 1394

ICTN چهارده ساله شد !

/۰ دیدگاه /در /توسط

14-years

شرکت ICTN ( فن آوران اطلاعات و ارتباطات شمالغرب ) ، با هدف ارائه ی راه حل های جامع و خدمات تخصصی بر مبنای متدولوژی های نوین در صنعت IT ، در سال ۱۳۸۱ شمسی در شهر تبریز تاسیس شد. ICTN با جذب فارغ التحصیلان ممتاز و با تجربه ی دانشگاه های کشور که دوره های مختلف در صنعت IT را با موفقیت طی کرده اند و عضویت در شورای عالی انفورماتیک، توانسته است خدمات ارزنده ای را برای سازمان ها، ادارات و شرکت های دولتی و خصوصی ارائه نماید.

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

حضور شرکت ICTN در الکامپ ۲۰۱۵

/۰ دیدگاه /در /توسط

elecomp-2015-news

 

به اطلاع مشتریان عزیز می رساند، شرکت ICTN از تاریخ ۲۳ تا ۲۶ آذر ماه ۹۴ در نمایشگاه الکامپ ۲۰۱۵ ، پذیرای علاقه مندان می باشد.

از تمامی عزیزان برای حضور در غرفه ICTN جهت آشنایی با محصولات جدید و پاسخگویی به سوالات توسط تیم فنی شرکت ICTN دعوت به عمل می‌آید.

منتظر دیدار شما در غرفه ICTN،  سالن 31A غرفه ۱۱۸ در نمایشگاه الکامپ هستیم.

Fast VP : اجازه دهید کارش را انجام دهد!

/۰ دیدگاه /در , /توسط

تمامی دیتا ها به طور یکسان مورد دسترسی قرار نمی گیرند. بعضی از دیتاها بصورت مداوم و بعضی دیگر به ندرت نیاز به دسترسی دارند. با توجه به معرفی و رونمایی قابلیت  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 کار خودش را انجام دهد؟ لطفا در این خصوص نظرات خود را با دوستان به اشترک گذارید.

بررسی Hot Spare و MCx Drive Mobility در VNX2

/۰ دیدگاه /در , /توسط

یک تغییر بزرگ در رده VNX2 نسبت به نسل پیشین خود یعنی VNX، جایگزینی Hto Spare Policy بجای انتخاب دائمی هارد دیسک Hot Spare است. در حالیکه در مدلهای پیشین می بایستی هارد دیسک های Hot Spare اختصاصی و از پیش تنظیم شده ای می داشتند که تنها در هنگام بروز خظا در یک هارد دیسک، مورد استفاده قرار می گرفتند، در رده VNX2 از هر هارد دیسک واجد الشرایط، استفاده نشده می توان بعنوان Spare بهره برد. در این آموزش سعی دارم تا مواردی را نظیر یافتن درایو جایگزین شده، یافتن درایو معیوب، عودت داده ها از درایو Hot Spare به درایو اصلی و .. را، ارائه نمایم.

  • یافتن دیسک اصلی و Hot Spare

برای مثال این سیستم را که دارای یک Pool شامل ۵۰ عدد هارد دیسک ۶۰۰ GB ، با سایز فیزیکی “۲.۵ و ۲ عدد هارد دیسک Unbound به عنوان Hot Spare است را در نظر بگیرید. در ابتدا هارد دیسک شماره 1_0_19 دچار خظا های Soft-Media می شود و در نهایت از بین می رود. فرآیند Rebuild هارد دیسک شماره 1_0_24 را انتخاب می نماید و شروع به بازسازی داده های می نماید. دو روز بعد هارد دیسک 1_0_24 نیز خطاهایی را نشان می دهد تا در نهایت این هارد دیسک نیز از بین می رود. آنگاه VNX2 هارد دیسک 0_0_4 را برای بازسازی داده ها در نظر می گیرد. داده هایی که اکنون بروی هارد دیسک 0_0_4 هستند، دیگر بروی هارد دیسک جایگزین شده 1_0_19 بر نمی گردند! این شیوه عملکرد Hot Spare در محصولات رده VNX2 است.پس شما چگونه می توانید دریابید که MCx داده های شما را به کدام دیسک جابجا کرده است؟ الان وقت آن است که به بررسی SP Event Log ها بپردازیم.

در Unisphere به آدرس زیر بروید :

System > Monitoring and Alerts > SP Event Logs

هر دوی SP Event Log ها را باز کنید. در مورد بررسی شده توسط بنده، Hot Spare Alert ها در SP B می باشد. شما می توانید زمان و تاریخ خرابی هارد دیسک را برا اساس زمان Alert بیابید. تا یافتن چیزی شبیه تصویر زیر به جستجو ادامه دهید.

 

همانگونه که ملاحظه می فرمایید هار دیسک 1_0_19 تولید Alert کرده ( تا خظ شماره ۷۶۰ ) و آنگاه دیسک 1_0_24 جایگزین آن شده است. ما می توانیم به همین شیوه نیز جیگزینی هارد دیسک دوم را نیز رصد کنیم.

خط ۳۱۷ در بالا نشان می دهد که در حال بازسازی داده های هارد دیسک 1_0_24 بروی هارد دیسک 0_0_4 می باشد. اگر شما می خواهید که تنها Event های مربوط به فرآیند Rebuild را مشاهده نمایید، می تواند در لیست Event ها، کد 0x7168 را Filter نمایید. حتی بدین گونه می توانید دریابید که آیا فرآیند Proactive Drive Replacement  نیز آغاز شده است و یا خیر؟.  برای نمونه در خطای اولیه دیسک، دیسک 1_0_19 تنها دچار خطا شده در حالیکه در خطای دوم فرآیند Proactive Copy  آغاز شده است. ( و تا کنون نیز به اتمام نرسیده است. )

 

در بیشتر موارد، شما تنها دیسک معیوب را با دیسک جایگزین تعویض نموده و سیستم به فعالیت خود بدون هیچگونه مشکای ادامه می دهد. اما اگر به هر دلیلی نیاز داشتید داده ها را بروی دیسک 1_0_19 باز گردانید، آنوقت چکار باید کرد؟

  • قابلیت MCx Drive Mobility

برای بازگرداندن داده ها به دیسک اصلی دو راهکار وجود دارد. اول اینکه شما می توانید با استفاده از دستور Copytodisk بدون نیاز به ترک صندلی تان (  خوشبختانه )، داده ها را به هارد دیسک اصلی بر گردانید. اما بیاد داشته باشید که این فرآیند بار زیادی را به تجهیز تحمیل می دارد، پس در این خصوص دقت لازم را بعمل آورید. راهکار دیگر استفاده از قابلیت MCx Drive Mobility است. بدین گونه که یک هارد دیسک را بمدت کمتراز ۵ دقیقه از تجهیز خارج نموده و مجددا آن را به تجهیز متصل نمایید تا تجهیز شما مجددا آنرا شناسایی نماید. بدون فرآیند Rebuild، سریع و ساده! . قابلیت MCx Drive Mobility با استفاده از شماره سریال هارد دیسک ها اعضای موجود در یک Pool را شناسایی می نماید و بر خلاف نسل پیشین خود VNX با جانمایی و محل فیزیکی قرار گیری هارد دیسک ها هیچ کاری ندارد. پس با خیال راحت می توانید هارد دیسک ها را در VNX 2 به لحاظ جانمایی به سادگی و حتی مابین DAE ها مختلف و بدون ریسک از دست رفتن داده ای موجود بروی آنها، جابجا نمایید. تنها این نکته را رعایت نمایید ” قبل از ۵ دقیقه دیسک را مجددا به تجهیز متصل نمایید “. و همینطور قبل از انجام هر کاری مطمئن شوید که فرآیندهای Rebuild به اتمام رسیده باشند و مطمئن شوید که هیچگاه دیسکی را که در حال Rebuild است، را از تجهیز خارج نکنید. می توانید با استفاده از دستور زیر

naviseccli -h getdisk -rb

به عنوان نمونه

getdisk 0_0_4 –rb

از وضعیت و نحوه پیشرفت فرآیند Rebuild مطلع گردید. آنگاه، جای هارد دیسک ها را با یکدیگر جابجا نمایید و آنگاه Log نشیر تصویر ذیل خواهید دید.

 

به نظر بنده، قابلیت MCx Drive Mobility یک قابلیت شگفت آور است ولیکن قطعا بنده به هیچ کس توصیه نمی کنم که در محیطهای عملیاتی هارد دیسکهای خود را جابجا نماید. به خصوص DAE های ۲.۵ اینچی با ۲۵ عدد هارد دیسک کوچک، که بدلبل اندازه فیزیکی کوچک و تعداد بالا احتمال اشتباه را بیشتر می کند. همچنین این نکته را بیاد داشته باشید که چون شما در حال جابجا نمودن هارد دیسک های سالم هستید، دیگر LED با رنگ نارنجی نیز به عنوان راهنمای شما وجود ندارد. هر کس که کم و بیش با VNX کار کرده باشد می داند که شروع اعداد از صفر است، حال فرض کنید که شخصی به اشتباه از ۱ شروع به شمارش نماید و اشتباهاتی از این دست. پس مجددا توصیه می کنم : تا هنگامی که به کاری که انجام می دهید اشراف کامل ندارید و یا توجه کامل را ندارید، از دستور copytodiskاستفاده نمایید.

کسب رتبه یک از شورای عالی انفورماتیک کشور

/۰ دیدگاه /در /توسط

%d8%b1%d8%aa%d8%a8%d9%87-%db%8c%da%a9-%d8%a7%d9%86%d9%81%d9%88%d8%b1%d9%85%d8%a7%d8%aa%db%8c%da%a9

رتبه‌بندی شرکت‌های انفورماتیک که نام کامل آن «آیین‌نامه رتبه‌بندی و احراز صلاحیت شرکت‌های انفورماتیکی» است، آیین‌نامه‌ای است که شورای‌ عالی انفورماتیک کشور (زیرمجموعه معاونت برنامه‌ریزی و نظارت راهبردی سابق) بر اساس آن امتیازی بین ۱ تا ۷ به شرکت‌های کامپیوتری اختصاص می‌دهد. شرکت‌های کامپیوتری اعم از سخت‌افزاری، نرم‌افزاری، شبکه‌ای و… برای عقد قرارداد با شرکت‌ها و سازمان‌های دولتی ملزم به دریافت رتبه خود از این شورا هستند. رتبه یک به منزله بالاترین و رتبه ۷ به معنی پایین‌تر رتبه است.

شرکت ICTN در رتبه بندی امسال شورای عالی انفورماتیک در سه زمینه :

  • پشتیبانی
  • شبکه داده های رایانه ای
  • تولید و ارائه رایانه های غیر Main Frame

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

 

بررسی FAST Cache

/۰ دیدگاه /در , /توسط

تکنولوژی FAST Cache در EMC قابلیت بهبود عملکرد و سرعت را با استفاده از Flash دیسک ها بعنوان Secondary Cache، برای VNX به ارمغان می آورد.FAST Cache دست در دست DRAM گذاشته و باعث بالارفتن عملکرد کلی Storage می گردد. EMC توصیه می کند که در ابتدا از FLASH دیسک های خود بعنوان FAST Cache استفاده نمایید و آنگاه در صورت نیاز به سرعت و عملکرد بالاتر، از Flash دیسکها در FAST VP بهره ببرید. FAST Cache در تمامی مدلهای VNX  و همچنین CX4 وجود دارد و تنها برای بهره برداری از آن، نیاز به نصب Enabler آن است. FAST Cache می تواند هم در Traditional RAID ها و هم در Storage Pool ها استفاده شود.

نکته : FAST Cache در سطح POOL Wide Level است و نمی توان آن را تنها برای یک LUN خاص فعال نمود.

انجام تنظیمات اولیه FAST Cache بسیار ساده است. پس از افزودن تعداد لازم Flash دیسک، با مراجعه به ” Sysytem Properties ” در Unisphere می توانید با انتخاب هارد دیسک ها، Fast Cache را برای تجهیز VNX خود فعال نمایید.

و یا می توانید با استفاده از دستورات Navicli اقدام به انجام تنظیمات اولیه و مانیتور کردن FAST Cache نمایید. برای فعال کردن FAST Cache می توان از دستور زیر استفاده نمایید :

naviseccli -h SPA_IP cache -fast -create –disks disks -mode rw -rtype r_1

می توانید وضعیت FAST Cache خود را با دستور زیر مشاهده نمایید :

naviseccli -h SPA_IP cache -fast -info –status

 

اگر می خواهید FAST Cache را بروی یک Pool خاص، فعال و یا غیر فعال کنید، از دستور زیر استفاده نمایید :

naviseccli -h SPA_IP storagepool -modify -name “Pool_Name” -fastcache off/on

 

و برای بررسی اینکه FAST Cache بروی کدام Pool ها فعال است :

naviseccli -h SPA_IP storagepool -list –fastcache

اگر FAST Cache نیاز به هرگونه تغییری در ساختار داشته باشد، نیاز است که در ابتدا FAST Cache غیر فعال شود. غیر فعال کردن FAST Cache بمعنای حذف و پاک کردن تمامی Dirty Block ها موجود در FAST Cache و نوشتن تمامی آنها بروی هارد دیسک ها می باشد. بعد از غیر فعال شدن کامل FAST Cache، شما می توانید با آرایش مورد نظر، مجددا FAST Cache را راه اندازی نمایید.

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

بازه قابل استفاده FAST Cache بروی محصولات EMC، می تواند از 100GB در CX4-120 شروع و تا ۴.۲ TB در VNX-8000 خاتمه یابد. با هم نگاهی به ظرفیتهای قابل پشتیبانی توسط هر تجهیز می اندازیم :

CX4 Systems:

CX4-120 – 100GB

CX4-240 – 200GB

CX4-480 – 800GB

CX4-960 – 2000GB

VNX1 Systems:

VNX 5100 – 100GB

VNX 5300 – 500GB

VNX 5500 – 1000GB

VNX 5700 – 1500GB

VNX 7500 – 2100GB

VNX2 Systems:

VNX 5200 – 600GB

VNX 5400 – 1000GB

VNX 5600 – 2000GB

VNX 5800 – 3000GB

VNX 7600 – 4200GB

VNX 8000 – 4200GB

 

نکته : توجه داشته باشید که نه تنها برای ظرفیت، بلکه برای تعداد Flash دیسکهای حاضر در FAST Cache نیز محدودیت وجود دارد. برای نمونه می توانید به تصویر زیر مراجعه نمایید.

دیسک های FAST Cache بصورت RAID 1 یا همان Mirror هستند. این موضوع به دلیل این واقعیت است که دیسک های FAST Cache دارای I/O بسیار شدیدی هستند و باعث تولید حجم I/O بیش از بیشینه توصیه شده بروی هر BUS می گردند. تعداد دیسک های FAST Cache در ازای هر Back End BUS در هر سییستمی متفاوت است ولی ایده آل آن در CX/VNX1 برابر ۴ دیسک در ازای هر BUS و در VNX2 این مقدار برابر با ۸ دیسک. است در مورد CX/VNX1 این دستورالعمل وجود دارد که نباید یکی از این زوج هارد دیسک های Mirror شده برای FAST cache، بروی یک DAE و زوج دیگر آن بروی DAE دیگر قرار گیرد.

ترتیب هارد دیسک های که در FAST Cache مورد استفاده قرار می گیرند بدین شکل است :

اولین دیسک، اولین Primary

دومین دیسک، اولین Secondary

سومین دیسک ، دومین Primary

چهارمین دیسک، دومین Secondary

و به همین ترتیب …….

شما می توانید با استفاده از دستور زیر این RAID 1 های داخلی FAST Cache راببینید :

naviseccli -h SPA_IP getrg –EngineeringPassword

نکته : هیچ گاه در خصوص هارد دیسک های مورد استفاده در FAST Cache از ترکیب ظرفیتها مختلف هارد دیسک مثلا 100GB به همراه ۲۰۰ GB استفاده نکنید. در تجهیزات رده VNX دو نوع SSD وجود دارد :

FAST Cache SSD : از نوع Single-Level Cell یا همان SLC ها می باشند. این Flash دیسک ها برای FAST Cache در نظر گرفته شده اند و در ظرفیتهای ۱۰۰ GB و ۲۰۰ GB موجود هستند. البته از این نوع Flash دیسک ها نیز می توان در Tier 1 قابلیت FAST VP نیز استفاده نمود.

FAST VP SSD : از نوع Enterprise Multi-Level Cell یا همان eMLC ها می باشند. این Flash دیسک ها برای استفاده در Tier 1 قابلیت FAST VP در نظر گرفته شده اند. از آنها نمی توان برای FAST Cacheاستفاده نمود. این دیسک ها در ظرفیتهای ۱۰۰ GB، ۲۰۰ GB و ۴۰۰ GB موجود هستند.

نمونه ای از چیدمان هارد دیسک های FAST Cache در VNX 8000

تصویر زیر یک نمونه از یک VNX 8000 با بیشینه FAST Cache قابل پشتیبانی ( ۴۲ x 200 GB ) است. همانگونه که مشاهده می کنید، با توجه به وجود ۱۵ عدد DAE و یک DPE، سعی شده تا جای ممکن حجم I/O هارد دیسک های FAST Cashe، بروی تمامی BE ها توزیع شود تا بتوان به کمترین Latency ممکن دست یافت.

درون FAST Cache

Fast Cache بر پایه تکنولوژی ” Unified LUN ” تولید شده است؛ در نتیجه تمامی اطلاعات درون FAST Cache از دسترسی توسط تمامی دیگر LUN های درون تجهیز CX/VNX محفوظ است. FAST Cache یک حافظه Nonvolatile ( غیر فرار ) است که می تواند از قطع برق و یا خرابی SP، بدون مشکل گذر کند و همچنین بر خلاف DRAM پس از قطع / وصل برق نیازی به انجام فرآیند Re-Warm ندارد.

به هنگام تولید FAST Cache بخشی از DRAM برای رهگیری IO درون FAST Cache که به Memory Map نیز معروف است، اختصاص داده می شود. این Bitmap از FAST Cache دقیقا متناسب با سایز FAST Cache است. این جانمایی Memory چیزی در حدود ۱ MB در ازای هر ۱ GB از FAST Cache است.

با یک حجم بار سازگار، FAST Cache می تواند با کاهش Response Time ، عملکرد و سرعت تجهیز را افزایش دهد و IOPS بیشتری را تولید نماید.

SP ها قادرند تا با استفاده از DRAM خود، پردازشهای خود را Cache نماید، همچنین SP می تواند فرامین Write خود را یکی نماید و یا جهت افزایش سرعت Read از فرآیند Pre-Fetch استفاده نماید. اما به هر حال این عملیاتها نمی توانند جوابگوی I/O بسیار بالای Read با دسترسی تصادفی باشند و اینجاست که FAST Cache به ما کمک می کند. FAST Cache با پایش I/O روی SP ها و یافتن Block هایی که بصورت مداوم Read/Write روی آنها صورت می گیرد، با یک برنامه زمان بندی شده آنها را به FAST Cache تجهیز Promote می نماید.

افزایش سرعت فرآیند FLUSH

یک موضوع که لازم است یادآوری شود اینست که زمانی که سرعت VNX افزایش می یابد و IOPS و به طبع آن حجم بار تحمیلی افزایش می یابد، این به معنای فشار بیشتر به CPU هر SP است که در این شرایط CPU ها باید مدام تحت نظر گرفته شوند و مانیتور شوند. در خصوص حداکثر بار تحمیلی به CPU ها نیز راهنما ها و دستر العمل های وجود دارد، که در آینده نزدیک آنها را با شما به اشتراک می گذارم.

همچنین نوع بار تحمیلی به LUN برای فعال/غیر فعال بودن Fast Cache نیز، مهم است. به عنوان نمونه log file ها معمولا بصورت Sequentially روی LUN شروع به READ/Write میکنند.  در این سناریو، این LUN انتخاب مناسبی برای FAST Cache نیست زیرا که Flash دیسکها در برخورد با بلاک های بزرگ، تفاوتی زیادی به لحاظ سرعت با دیسکهای چرخشی ندارند.

همچنین توصیه می شود که Block های بزرگ با نوع دسترسی Sequential، بهتر است توسط زیاد هارد دیسک سرویس دهی شوند. ارائه این نوع Block ها به FAST Cache یعنی نگهداری انها روی تعداد کمی هارد دیسک و این یعنی، کاهش عملکرد تجهیز cialis genérico en españa. عدم استفاده از Fast Cache برویLUN های غیر مناسب، می تواند باعث کاهش فرآیند رهگیری و Promote به FAST Cache شود تا این توان تجهیز در جای مناسب تری هزینه شود.

روش برنامه ریزی و محاسبه سرعت در EMC VNX – POOL

/۰ دیدگاه /در , /توسط

 

در این آموزش قصد دارم یک راهنما برای روش محاسبه تعداد و نوع هارد دیسک های مورد نیاز یک Pool بر اساس ( Throughput ( IOPS مورد نیاز، ارائه نمایم. این روش یک شیوه Rough-Order-of Magnitude یا همان ROM است که در خروجی تقریبی از تعداد هارد دیسک های مورد نیاز به شما ارائه می نماید. پیشنهاد می شود قبل از اقدام به تواید LOM خود، در این خصوص حتما از مشاوره و راهنمایی یک متخصص EMC در این زمینه بهره ببرید.

در ابتدا قصد داریم تاثیر انواع مختلف RAID ها را دریابیم. تفاوت اصلی میان RAID های مختلف در سرعت و عملکرد Write آنها می باشد. این در حالی است که سرعت و عملکرد Read در تمامی انواع RAID ها یکی است. برای فرآیند Write در انواع RAID ها داریم :

  • Mirrored RAID 1/0 : ۱ Host Write = 2 Writes
  • Parity RAID 5 : ۱ Host Write = 2 Reads + 2 Writes
  • Parity RAID 6 : ۱ Host Write = 3 Reads + 3 Writes

پس با در نظر گرفتن موارد فوق برای محاسبه IOPS تولید شده از یک RAID داریم :

Parity R A I D 5

Drive IOPS = Read IOPS + 4xWrite IOPS

Parity R A I D 6

Drive IOPS = Read IOPS + 6xWrite IOPS

Mirrored R A I D 1/0

Drive IOPS = Read IOPS + 2xWrite IOPS

به عنوان یک مثال، فرض کنید که بر اساس نرم افزارهای کنترلی و یا بنا به پیشنهاد تولید کننده نرم افزار، هاست شما به IOPS برابر با ۲۰,۰۰۰  با ضریب ۸۰% برای Read و ۲۰%  برای Write نیاز دارد. فرض بگیریم نوع RAID پیشنهاد شده نیز RAID 5 است. حال نیاز داریم که بتوانیم برای این نرم افزار تعداد و نوع هارد دیسک های مورد نیاز را محاسبه نماییم.

Drive IOPS = (0.8 x ۲۰,۰۰۰ + ۴ x (۰.۲ x ۲۰,۰۰۰))

Drive IOPS = 32,000

پس من باید یک هارد دیسک ( قطعا Logical ) با IOPS برابر ۳۲.۰۰۰ برای عملکرد مناسب نرم افزار در اختیار هاست قرار دهم.

تخمین تعداد دیسکهای مورد نیاز بر اساس IOPS

بر اساس جدول ارائه شده ، با انجام محاسبات بسیار ساده ای می توان تعداد هارد دیسک های مورد نیاز هر Pool را تخمین زد. در مثال ارائه شده فرض بر وجود نرم افزارهایی با Small-Block Random I/Oنظیر DataBase ها با Block Size های نظیر 16KB و یا کوچکتر از آن است.

فرض کنید ما می خواهیم برای این منظور، از هارد دیسک های SAS 15K در یک Homogenous Pool استفاده کنیم. در این حالت با توجه به IOPS مورد نیاز یعنی ۳۲.۰۰۰  با انجام یک محاسبه ساده داریم :

۳۲۰۰۰  IOPS / 180 IOPS PER DISK = 177.8 Disks

با توجه به اینکه قرار است ما از RAID 5 استفاده نماییم و در این نوع RAID ما انتخاب های ۴+۱ و یا ۸+۱ داریم، ( در آموزش ” Storage Pools در مقابل RAID Groups ” در این خصوص توضیحات لازمه ارائه شده است. ) بنابراین ما ۱۸۰ عدد هارد دیسک نیاز داریم. در نتیجه اگر از ۴+۱۱ استفاده کنیم داریم :

۳۶ x RAID 5 ( 4+1 ) Private RAID Groups

در حالت دوم می توان متصور بود که با استفاده از تکنولوژی FAST VP یک Heterogeneous Pool با دو Tier با استفاده از هارد دیسک های Flash و SAS تولید می کنیم. برای این منظور از ۵ عدد Flash دیسک برای تولید IOPS و کاهش تعداد دیسک های SAS استفاده می کنیم. در این حالت داریم :

IOPS تولید شده تنها توسط ۵ عدد SAS Flash VP

۵  X 3500IOPS ( SAS Flash VP ) = 17,500 IOPS

در این وضعیت IOPS باقیمانده برابر ۱۸.۵۰۰ می باشد که این IOPS بایستی توسط هارد دیسکهای SAS 15K تامین شود. برای این منظور داریم :

۱۸,۵۰۰ / ۱۸۰ = 102,۷

 با در نظر گرفتن RAID 5 بصورت ۴+۱ ، ما به ۱۰۵ هارد دیسک SAS 15K نیاز داریم.

در نتیجه با بهره گیری از تکنولوژی FAST VP ما تعداد ۷۰ عدد هارد دیسک کمتر نسبت به حالت Homogenous Pool ( حالت اول ) نیاز داریم. این قدرت Flash دیسکها است.

لطفا همیشه به خاطر داشته باشید که ۴ هارد دیسک اولی روی تجهیز، هاردهای Vault نامیده می شوند و در محاسبه سرعت و ظرفیت تجهیز هیچ نقشی ندارند.

 

Call Now Button