Dell EMC Storage و مترونود

در طول این مقاله، نشان خواهیم داد که powerstor metronode برای Dell EMC Storage چگونه  قابلیت های فعال مترواکتیو را تحویل میدهد. همچنین این برای دو حالت در نظر گرفته میشود یکی برای زمانی که فاجعه رخ میدهد و دیگری برای زمانی که هیچ تاثیری روی مسیر داده نمیگذارد و این هارا برای دستگاه های Dell EMC Storage نشان خواهیم داد.

مترونود (metronode) پتانسیل کامل یک پیکربندی مترو را به نمایش می گذارد. یک معماری واقعاً مقاوم در برابر بلایا که تداوم کسب و کار را بدون نیاز به دخالت کاربر امکان پذیر می کند. حالا قبل از اینکه وارد نمایش این موضوع  شویم ابتدا اجازه دهید در مورد اینکه پیکربندی مترونوم چگونه به نظر می رسد کمی توضیح دهیم. با استفاده از دو سایت در حجم مرزهای جغرافیایی مترو حجم ها به صورت جفت شده اند و به صورت یک حجم مجازی به میزبان ارائه شده است. به این حجم مجازی به عنوان دو پا که یکسان هستند فکر کنید همیشه دسترسی فعال خواندن و نوشتن دارند  همیشه با یکدیگر همگام می شوند در صورت خرابی در سایت یک، سایت دو دارای یک نسخه مشابه است و به طور مداوم در دسترس میزبان است. از دیدگاه میزبان اتصال به حجم داده قطع نمی شود و همچنین داده ها از دست نمی روند یا اقدامات بازیابی مورد نیاز نیست. با نصب یک سرور شاهد بر روی یک دامنه خطای جداگانه، شما متوانید در برابر هر گونه سناریوهای انشعاب مغزی که ممکن است زمانی اتفاق بیفتد که یک metronode اتصال خود به دیگری را از دست دهد، محافظت کنید. این اجازه می دهد تا Failover به طور خودکار و بدون هیچ گونه مشکل و مداخله کاربر اتفاق بیفتد. به همین ترتیب هنگامی که یک سایت در دسترس می شود دوباره مترونود به طور خودکار بازیابی می شود و به همگام سازی داده های شما ادامه می دهد. آخرین چیزی که می خواهم قبل از ادامه به آن اشاره کنم این است که مترونود عملکرد صفر در تاثیر بر ذخیره سازی شما دارد. زیرا ما واقعاً در آنجا فعال هستیم. هیچ هزینه یا سربار مخفی مانند یک مترو شبه یا تنظیمات غیرفعال  یا فعال پیکربندی ندارد. با مترونود شما پتانسیل کامل از هر سیستم ذخیره سازی را دریافت می کنید و چیزی در حال انتظار باقی نمانده است. در چند ثانیه از تهیه یک حجم مجازی با استفاده از کتاب‌های نمایشی قابل عبور می کنیم و در ادامه شبیه سازی میکنیم که چه سناریوی فاجعه ای میتواند وجود داشته باشد. قبل از شروع، اجازه دهید به طور خلاصه مرور کنیم محیط metronode ما چگونه به نظر می رسد. در سمت چپ نمودار توپولوژی، سایت 1 را با استفاده از powerstor 3000t که به عنوان ذخیره سازی پشتیبان زیرین (underlying back-end storage) میباشد داریم. این از طریق sandfabric به مترونود متصل می شود در قسمت جلویی( front end ) ما یک vmware esx داریم که  میزبان ماشین های مجازی ما را خوشه بندی میکند.در سمت راست نمودار توپولوژی ما یک پیکربندی بسیار مشابه داریم به جز اینکه ما در عوض از پاورستور 1000x به عنوان ذخیره سازی پشتیبان زیرین(underlying back-end storage) استفاده می کنیم. مترونود با ذخیره سازی ناهمگن به صورت یکپارچه کار می کند در واقع شما می توانید ذخیره سازی های مختلف را مخلوط کنید. محصولاتی مانند dell emc unity xt on one و از طرف دیگر یک منبع تغذیه را مخلوط کنید.اکنون در وسط نمودار ما مشتریان ماشین مجازی خود را داریم که حجم های مجازی ارائه شده مختلف دارند. در پشت صحنه حجم های مجازی در هر سایت یک پا دارد که همیشه همگام سازی می شود داشته باشید اما از نظر میزبان این فقط به عنوان یک جلد نمایش داده می شود. مترونود نیز روی گرانول انتخاب حجم کار، کار می کند این به شما امکان می دهد تا هر حجم که از قابلیت های مترو میخواهید استفاده کنید را انتخاب کنید. این به حداقل رساندن هزینه کمک می کند و نیاز به داشتن انواع سیستم یکسان در هر مکان را نفی می کند.

با استفاده از ansible ما می توانیم فرآیند تامین یک حجم مجازی  را خودکار کنیم. همانطور که می بینید در اینجا ابتدا ما جلدهای اساسی از سیستم های ذخیره برق سایت 1 و 2 را ایجاد می کنیم. سپس اینها توسط metronode کشف می شوند  و یک حجم مجازی یکربندی میشود. در نهایت حجم مجازی به خوشه vmware مشخص شده ارائه میشود. همانطور که ببینید با استفاده از ansible  کل فرآیند تامین همه موارد را در بر گرفت و تکمیل آن حدود 15 ثانیه طول کشید.

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

در اینجا قبلاً پیش رفته ایم و حجم مجازی به عنوان یک نقشه دستگاه خام به یک ماشین مجازی در خوشه esx را ارائه کرده ایم. همانطور که می بینید در اینجا شروع به راه اندازی حجم کاری استفاده از نیمکت vd روی کرده ایم.

ما به مدیریت منبع برق می رویم همچنین می توانید نگاهی به هر سیستم ذخیره سازی بیندازید. در پاورستور3000t  ما می توانیم ببینیم io  در حال اجرا است و اگر تغییر دهیم و به پاور استور 1000x نگاه کنیم ما همچنین می توانیم ببینیم که i o در حال اجرا شدن در پای دوم است. این نشان می دهد که ما یک پیکربندی واقعاً فعال داریم. حالا حجم مجازی ارائه شده و حجم کاری در حال اجرا بر روی آن است.

بیایید ببینیم وقتی یک بلای طبیعی رخ می دهد چه اتفاقی می افتد. در این مثال یک فاجعه را با حذف شبکه اتصال از منبع برق در سایت 1. شبیه سازی کرده ام. این می تواند به طرق مختلف اتفاق بیفتد، مانند چیزی جزئی مثل  یک پنجره تعمیر و نگهداری غیر منتظره یا حتی چیزی به اندازه از دست دادن بینایی کل در اثر بلایای طبیعی، مهم است. هر سناریویی باشد اگر به metronode interface برگردیم می توانیم ببینیم که خوشه سایت یک در حال حاضر یک شکست را نشان می دهد.

اگر به حجم مجازی خود برویم همچنین می توانیم ببینیم که در خود حجم، خرابی وجود دارد. با مشاهده نقشه مجازی حجم می بینیم که ما نیز یکی از پایه های زیرین ذخیره ساز(underlying legs of storage) را از دست داده ایم. اما با بازرسی پای باقی مانده ما می توانیم ببینیم که وضعیت سرویس در حال اجرا و عملکرد دستگاه ثابت است.

با جابجایی به پاورستور 3000t  که فضای ذخیره سازی سایتی است که  اتصال را از دست داده، می بینیم همانطور که انتظار میرفت io به صفر رسیده است. اکنون به منبع برق 1000x  نگاه می کنیم که پای باقی مانده انبار است، ما می بینیم که io هنوز ادامه دارد و قطع یا رها نشده است.

ما همچنین برخی از فعالیت های نوشتن های اضافی را دیدیم. اما این مورد انتظار می رود زیرا مرحله دوم در حال حاضر تمام i/o را بر عهده می گیرد. در نهایت اگر به فضای مجازی خود نگاهی بیندازیم می بینیم که volume متصل مانده است و حجم کار هنوز به طور معمول در حال اجرا است در این حالت هیچ خطایی یا مهلت زمانی وجود ندارد.

بیایید آنچه را که از این آموخته ایم مرور کنیم.

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