سلام خوانندگان هابر! در آخرین مقاله، ما در مورد یک ابزار ساده برای بازیابی فاجعه در سیستم های ذخیره سازی AERODISK ENGINE - تکرار صحبت کردیم. در این مقاله، ما به موضوع پیچیده‌تر و جالب‌تری خواهیم پرداخت - یک متروکلاستر، یعنی یک ابزار خودکار حفاظت از بلایا برای دو مرکز داده که به مراکز داده اجازه میدهد در حالت فعال-فعال کار کنند. می گوییم، نشان می دهیم، می شکنیم و درست می کنیم.
طبق معمول، در ابتدای نظریه
متروکلاستر خوشه‌ای است که در چندین مکان در یک شهر یا منطقه قرار دارد. کلمه "خوشه" به وضوح به ما اشاره می کند که مجتمع خودکار است، یعنی تعویض گره های خوشه در صورت خرابی (failover) به طور خودکار انجام می شود.
اینجاست که تفاوت اصلی بین متروکلاستر و تکرار منظم نهفته است. اتوماسیون عملیات. یعنی در صورت بروز حوادث خاص (از کار افتادن مرکز داده، شکستن کانال ها و ...) سیستم ذخیره سازی به طور مستقل اقدامات لازم را برای حفظ در دسترس بودن داده ها انجام می دهد. هنگام استفاده از کپی های معمولی، این اقدامات به طور کامل یا جزئی به صورت دستی توسط مدیر انجام می شود.
چه کاری انجام میدهد؟
هدف اصلی که مشتریان با استفاده از پیاده‌سازی‌های متروکلاستر خاص دنبال می‌کنند، به حداقل رساندن RTO (هدف زمان بازیابی) است. یعنی به حداقل رساندن زمان بازیابی خدمات فناوری اطلاعات پس از خرابی. اگر از تکرار معمولی استفاده می کنید، زمان بازیابی همیشه بیشتر از زمان بازیابی با یک کلاستر مترو خواهد بود. چرا؟ بسیار ساده. مدیر باید در محل کار باشد و تکرار را به صورت دستی تغییر دهد، در حالی که کلاستر مترو این کار را به صورت خودکار انجام می دهد.
اگر یک مدیر وظیفه اختصاصی ندارید که نمی‌خوابد، غذا نمی‌خورد، سیگار نمی‌کشد یا بیمار نمی‌شود، اما 24 ساعت شبانه‌روز به وضعیت سیستم ذخیره‌سازی نگاه می‌کند، هیچ‌گونه تضمینی وجود ندارد که مدیر این کار را انجام دهد. برای تعویض دستی در هنگام خرابی در دسترس باشد.
بر این اساس، RTO در صورت عدم وجود خوشه مترو یا ادمین جاویدان سطح 99 سرویس وظیفه مدیران برابر است با مجموع زمان سوئیچینگ کلیه سیستم ها و حداکثر مدت زمانی که پس از آن مدیر تضمین می شود شروع به کار با سیستم ذخیره سازی و سیستم های مرتبط.
بنابراین، ما به این نتیجه واضح می رسیم که اگر نیاز به RTO دقیقه باشد، نه ساعت یا روز، باید از متروکلاستر استفاده شود، یعنی زمانی که در صورت وحشتناک ترین سقوط مرکز داده، بخش فناوری اطلاعات باید ارائه دهد. کسب و کار با زمان برای بازگرداندن دسترسی به خدمات فناوری اطلاعات در عرض چند دقیقه یا حتی چند ثانیه.
چگونه کار می کند؟
در سطح پایین تر، متروکلاستر از مکانیسم تکثیر داده همزمان استفاده می کند که در مقاله قبلی توضیح دادیم (به زیر مراجعه کنید). ). از آنجایی که همانندسازی همزمان است، الزامات آن مناسب است، یا بهتر است بگوییم:
- فیبر به عنوان فیزیک، اترنت 10 گیگابیتی (یا بالاتر)؛
- فاصله بین مراکز داده بیش از 40 کیلومتر نیست.
- تاخیر کانال نوری بین مراکز داده (بین سیستم های ذخیره سازی) تا 5 میلی ثانیه (بهینه 2).
همه این الزامات ماهیت مشاوره ای دارند، یعنی حتی اگر این الزامات برآورده نشود، خوشه مترو کار خواهد کرد، اما باید درک کرد که عواقب عدم رعایت این الزامات برابر با کند کردن عملکرد هر دو سیستم ذخیره سازی است. در خوشه مترو
بنابراین، یک کپی همزمان برای انتقال داده ها بین سیستم های ذخیره سازی استفاده می شود، اما چگونه کپی ها به طور خودکار سوئیچ می شوند و مهمتر از همه، چگونه از تقسیم مغز جلوگیری کنیم؟ برای انجام این کار، در سطح بالا، از یک موجود اضافی استفاده می شود - داور.
داور چگونه کار می کند و وظیفه او چیست؟
Arbiter یک ماشین مجازی کوچک یا یک خوشه سخت افزاری است که باید در یک سایت سوم (مثلاً در یک دفتر) راه اندازی شود و از طریق ICMP و SSH به فضای ذخیره سازی دسترسی داشته باشد. پس از شروع، داور باید IP را تنظیم کند، و سپس آدرس آن را از سمت ذخیره سازی، به اضافه آدرس های کنترل از راه دور که در خوشه مترو شرکت می کنند، مشخص کند. پس از آن داور آماده حرکت است.
داور دائماً تمام سیستم‌های ذخیره‌سازی را در خوشه مترو نظارت می‌کند و در صورتی که یک سیستم ذخیره‌سازی خاص در دسترس نباشد، پس از تأیید در دسترس نبودن یکی دیگر از اعضای خوشه (یکی از سیستم‌های ذخیره‌سازی «زنده»)، تصمیم می‌گیرد تا این روند را آغاز کند. تغییر قوانین تکرار و نقشه برداری
یک نکته بسیار مهم داور باید همیشه در مکانی متفاوت از مکان‌هایی باشد که سیستم‌های ذخیره‌سازی در آن قرار دارند، یعنی نه در DPC 1، جایی که ذخیره‌سازی 1 قرار دارد، و نه در DPC 2، که ذخیره‌سازی 2 در آن نصب شده است.
چرا؟ زیرا تنها از این طریق است که داور می تواند با کمک یکی از سیستم های ذخیره سازی باقیمانده، سقوط هر یک از دو سایتی که سیستم های ذخیره سازی در آن نصب شده اند را بدون ابهام و با دقت مشخص کند. هر روش دیگری برای قرار دادن داور ممکن است منجر به شکاف مغزی شود.
حالا بیایید به جزئیات کار داور بپردازیم.
چندین سرویس بر روی داور اجرا می شوند که به طور مداوم همه کنترل کننده های ذخیره سازی را نظرسنجی می کنند. اگر نتیجه نظرسنجی با قبلی (در دسترس/غیرقابل دسترس) متفاوت باشد، در یک پایگاه داده کوچک که روی داور نیز کار می کند، نوشته می شود.
منطق داور را با جزئیات بیشتری در نظر بگیرید.
مرحله 1. تعیین عدم دسترسی. رویدادی که سیگنال خرابی سیستم ذخیره سازی را نشان می دهد، عدم وجود پینگ از هر دو کنترل کننده یک سیستم ذخیره سازی به مدت 5 ثانیه است.
مرحله 2. شروع روش تعویض. پس از اینکه داور متوجه شد که یکی از سیستم های ذخیره سازی در دسترس نیست، درخواستی را به سیستم ذخیره سازی "زنده" ارسال می کند تا مطمئن شود که سیستم ذخیره سازی "مرده" واقعاً مرده است.
پس از دریافت چنین دستوری از داور، سیستم ذخیره سازی دوم (زنده) علاوه بر این، در دسترس بودن سیستم ذخیره سازی اول سقوط کرده را بررسی می کند و در غیر این صورت، تایید حدس خود را برای داور ارسال می کند. SHD، در واقع، در دسترس نیست.
پس از دریافت چنین تاییدی، داور یک رویه از راه دور را برای تغییر تکرار و بالا بردن نقشه روی آن دسته از ماکت هایی که در سیستم ذخیره سازی سقوط کرده فعال (اولیه) بودند، شروع می کند و دستوری را به سیستم ذخیره سازی دوم می فرستد تا این ماکت ها از ثانویه به اولیه بسازند. و نقشه برداری را بالا ببرید. خب، سیستم ذخیره سازی دوم، به ترتیب، این رویه ها را انجام می دهد، پس از آن، دسترسی به LUN های از دست رفته را از خود فراهم می کند.
چرا تأیید اضافی مورد نیاز است؟ برای حد نصاب. یعنی اکثریت کل تعداد فرد (3) اعضای خوشه باید سقوط یکی از گره های خوشه را تایید کنند. تنها در این صورت است که این تصمیم دقیقاً درست خواهد بود. این برای جلوگیری از تعویض اشتباه و بر این اساس، تقسیم مغز ضروری است.
مرحله 2 حدود 5-10 ثانیه طول می کشد، بنابراین، با در نظر گرفتن زمان مورد نیاز برای تعیین عدم دسترسی (5 ثانیه)، در عرض 10-15 ثانیه پس از خرابی، LUN هایی با یک سیستم ذخیره سازی افتاده به طور خودکار برای کار با زنده در دسترس خواهند بود. ذخیره سازی.
واضح است که برای جلوگیری از قطع ارتباط با هاست، باید مراقب تنظیم صحیح تایم اوت ها نیز باشید. مدت زمان توصیه شده حداقل 30 ثانیه است. این امر مانع از قطع اتصال به حافظه توسط میزبان در هنگام بارگذاری شکست می شود و می تواند اطمینان حاصل کند که هیچ وقفه ای در I/O وجود ندارد.
یک لحظه صبر کنید، معلوم می شود که اگر همه چیز با خوشه مترو خوب است، اصلاً چرا به تکرار منظم نیاز داریم؟
در واقع، همه چیز به این سادگی نیست.
جوانب مثبت و منفی متروکلاستر را در نظر بگیرید
بنابراین، متوجه شدیم که مزایای آشکار متروخوشه در مقایسه با همانندسازی معمولی عبارتند از:
- اتوماسیون کامل، تضمین حداقل زمان بازیابی در صورت وقوع فاجعه؛
- و بس :-).
و اکنون، توجه، معایب:
- هزینه راه حل اگرچه متروکلاستر در سیستم‌های Aerodisk به مجوز اضافی نیاز ندارد (همان مجوزی که برای ماکت استفاده می‌شود)، هزینه راه‌حل همچنان حتی از استفاده از تکرار همزمان نیز بالاتر خواهد بود. شما باید تمام الزامات یک ماکت همزمان، به علاوه الزامات برای خوشه مترو مرتبط با سوئیچینگ اضافی و سایت اضافی را اجرا کنید (به برنامه ریزی خوشه مترو مراجعه کنید).
- پیچیدگی تصمیم. یک متروکلاستر بسیار پیچیده تر از یک کپی معمولی است و برای برنامه ریزی، پیکربندی و مستندسازی به توجه و تلاش بسیار بیشتری نیاز دارد.
در نهایت. Metrocluster مطمئناً یک راه حل بسیار فناورانه و خوب است که واقعاً نیاز به ارائه RTO در چند ثانیه یا چند دقیقه دارید. اما اگر چنین وظیفه ای وجود نداشته باشد، و RTO در چند ساعت برای تجارت مناسب باشد، شلیک گنجشک ها از یک توپ منطقی نیست. تکرار معمول کارگر-دهقان کافی است، زیرا خوشه مترو باعث هزینه های اضافی و پیچیدگی زیرساخت فناوری اطلاعات خواهد شد.
برنامه ریزی خوشه ای مترو
این بخش قصد ندارد یک آموزش جامع در مورد طراحی خوشه مترو باشد، بلکه فقط جهت‌های اصلی را نشان میدهد که اگر تصمیم به ساختن چنین سیستمی دارید، باید در مورد آنها کار کنید. بنابراین در حین اجرای واقعی خوشه مترو حتما سازنده سیستم ذخیره سازی (یعنی ما) و سایر سیستم های مرتبط را برای مشاوره درگیر کنید.
مکان های برگزاری
همانطور که در بالا گفته شد، یک خوشه مترو به حداقل سه سایت نیاز دارد. دو مرکز داده، که در آن سیستم‌های ذخیره‌سازی و سیستم‌های مرتبط کار خواهند کرد، و همچنین یک سایت سوم که داور در آن کار خواهد کرد.
فاصله توصیه شده بین مراکز داده بیش از 40 کیلومتر نیست. فاصله بیشتر به احتمال زیاد باعث تأخیرهای اضافی می شود که در مورد خوشه مترو بسیار نامطلوب است. به یاد داشته باشید که تاخیرها باید تا 5 میلی ثانیه باشد، اگرچه مطلوب است که در 2 نگه داشته شود.
همچنین توصیه می شود که تاخیرها در طول فرآیند برنامه ریزی بررسی شوند. هر ارائه‌دهنده کم و بیش بزرگسالی که فیبر بین مراکز داده را فراهم می‌کند، می‌تواند به سرعت یک بررسی کیفیت را سازماندهی کند.
در مورد تاخیرهای داور (یعنی بین سایت سوم و دو سایت اول)، آستانه تاخیر توصیه شده تا 200 میلی ثانیه است، یعنی یک اتصال VPN شرکتی معمولی از طریق اینترنت انجام می شود.
سوئیچینگ و شبکه
بر خلاف طرح تکرار، که در آن کافی است سیستم‌های ذخیره‌سازی را از سایت‌های مختلف متصل کنیم، طرح خوشه مترو نیازمند اتصال میزبان‌ها به هر دو سیستم ذخیره‌سازی در سایت‌های مختلف است. برای روشن تر شدن تفاوت، هر دو طرح در زیر فهرست شده اند.
همانطور که از نمودار می بینید، ما هاست های سایت 1 داریم که هم به ذخیره سازی 1 و هم به استوریج 2 نگاه می کنند. همچنین، برعکس، هاست های سایت 2 هم به ذخیره سازی 2 و هم به ذخیره سازی 1 نگاه می کنند. یعنی هر میزبان هر دو سیستم ذخیره سازی را می بیند. این یک پیش نیاز برای عملکرد مترو کلاستر است.
البته نیازی به کشیدن هر هاست با سیم نوری به مرکز داده دیگر نیست، پورت ها و سیم های کافی وجود نخواهد داشت. همه این اتصالات باید از طریق سوئیچ های Ethernet 10G+ یا FibreChannel 8G+ انجام شوند (FC فقط برای اتصال میزبان ها و ذخیره سازی برای IO، کانال تکرار در حال حاضر فقط از طریق IP (Ethernet 10G+) در دسترس است.
حالا چند کلمه در مورد توپولوژی شبکه. نکته مهم پیکربندی صحیح زیرشبکه ها است. شما باید بلافاصله چندین زیرشبکه برای انواع ترافیک زیر تعریف کنید:
- زیرشبکه برای تکرار، که داده ها بین سیستم های ذخیره سازی از طریق آن همگام می شوند. ممکن است چندین مورد از آنها وجود داشته باشد، در این مورد مهم نیست، همه اینها به توپولوژی شبکه فعلی (از قبل اجرا شده) بستگی دارد. اگر دو مورد از آنها وجود داشته باشد، بدیهی است که مسیریابی بین آنها باید پیکربندی شود.
- زیرشبکه های ذخیره سازی که از طریق آن هاست ها به منابع ذخیره سازی دسترسی خواهند داشت (اگر iSCSI باشد). در هر مرکز داده باید یک زیر شبکه وجود داشته باشد.
- زیرشبکه‌های کنترل، یعنی سه زیرشبکه قابل مسیریابی در سه سایت که ذخیره‌سازی از آنها مدیریت می‌شود و داور نیز در آنجا قرار دارد.
ما در اینجا زیرشبکه‌ها را برای دسترسی به منابع میزبان در نظر نمی‌گیریم، زیرا آنها به شدت به وظایف وابسته هستند.
جداسازی ترافیک مختلف به زیرشبکه های مختلف بسیار مهم است (به ویژه مهم است که ماکت را از I / O جدا کنید)، زیرا اگر تمام ترافیک را در یک زیر شبکه "ضخیم" ترکیب کنید، مدیریت این ترافیک غیرممکن خواهد بود. شرایط دو مرکز داده هنوز هم می تواند گزینه های مختلف برخورد شبکه را ایجاد کند. ما در چارچوب این مقاله عمیقاً به این موضوع نخواهیم پرداخت ، زیرا می توانید در مورد برنامه ریزی شبکه ای که بین مراکز داده در منابع تولید کنندگان تجهیزات شبکه کشیده شده است بخوانید ، جایی که این با جزئیات زیاد توضیح داده شده است.
پیکربندی داور
داور باید دسترسی به تمام رابط های کنترلی سیستم ذخیره سازی را از طریق پروتکل های ICMP و SSH فراهم کند. همچنین باید به تحمل خطای داور فکر کنید. در اینجا یک نکته ظریف وجود دارد.
خطای Arbiter بسیار مطلوب است، اما الزامی نیست. و اگر داور در زمان نامناسبی سقوط کند چه اتفاقی می افتد؟
- عملکرد متروکلاستر در حالت عادی تغییر نخواهد کرد، زیرا arbtir به هیچ وجه بر عملکرد متروکلاستر در حالت عادی تأثیر نمی گذارد (وظیفه آن این است که بار را به موقع بین مراکز داده جابجا کنید)
- در همان زمان، اگر داور به هر دلیلی بیفتد و تصادف را در مرکز داده "خواب" کند، هیچ تغییری رخ نخواهد داد، زیرا کسی وجود نخواهد داشت که دستورات سوئیچینگ لازم را بدهد و حد نصاب را سازماندهی کند. در این حالت، خوشه مترو به یک طرح تکراری معمولی تبدیل می‌شود، که باید در هنگام فاجعه به‌طور دستی سوئیچ شود، که بر RTO تأثیر می‌گذارد.
چه چیزی از این نتیجه می شود؟ اگر واقعاً نیاز به ارائه حداقل RTO دارید، باید از تحمل خطای داور اطمینان حاصل کنید. دو گزینه برای این وجود دارد:
- یک ماشین مجازی را با یک آربیتر بر روی یک هایپروایزر مقاوم در برابر خطا اجرا کنید، زیرا همه هایپروایزرهای بزرگسال از تحمل خطا پشتیبانی می کنند.
- اگر در سایت سوم (در یک دفتر مشروط) نصب یک کلاستر معمولی بسیار تنبل است و هیچ خوشه ای از هایپروایزر وجود ندارد، ما یک نسخه سخت افزاری از داور ارائه کرده ایم که در یک جعبه 2U ساخته شده است که در آن دو سرورهای معمولی x-86 کار می کنند و می توانند از شکست محلی جان سالم به در ببرند.
ما قویاً توصیه می کنیم که از تحمل خطای داور اطمینان حاصل کنید، علیرغم این واقعیت که خوشه مترو در حالت عادی به آن نیاز ندارد. اما همانطور که تئوری و عمل نشان می دهد، اگر یک زیرساخت واقعا قابل اعتماد برای تحمل بلایا ایجاد می کنید، بهتر است آن را ایمن کنید. بهتر است از خود و کسب و کار خود در برابر "قانون پست"، یعنی از شکست داور و یکی از سایت هایی که سیستم ذخیره سازی در آن قرار دارد، محافظت کنید.
معماری راه حل
با توجه به الزامات بالا، معماری راه حل کلی زیر را دریافت می کنیم.
LUN ها باید به طور مساوی در بین دو سایت توزیع شوند تا از ازدحام شدید جلوگیری شود. در عین حال، هنگام اندازه‌گیری در هر دو مرکز داده، نه تنها باید حجم دو برابر (که برای ذخیره داده‌ها به طور همزمان در دو سیستم ذخیره‌سازی ضروری است) ارائه شود، بلکه برای جلوگیری از عملکرد دو برابری در IOPS و MB / s نیز لازم است. تخریب برنامه ها در صورت خرابی یکی از مراکز داده - ov.
به طور جداگانه متذکر می شویم که با رویکرد مناسب به اندازه (یعنی به شرطی که محدودیت های بالای مناسب IOPS و MB / s و همچنین منابع CPU و RAM لازم را در نظر گرفته باشیم)، اگر یکی از سیستم های ذخیره سازی در خوشه مترو از کار می افتد، در شرایط کار موقت روی یک سیستم ذخیره سازی، افت عملکرد جدی وجود نخواهد داشت.
این با این واقعیت توضیح داده می شود که در شرایطی که دو سایت به طور همزمان کار می کنند ، اجرای تکرار همزمان نیمی از عملکرد نوشتن را "می خورد" ، زیرا هر تراکنش باید در دو سیستم ذخیره سازی (مشابه RAID-1 / 10) نوشته شود. بنابراین، اگر یکی از سیستم های ذخیره سازی از کار بیفتد، اثر تکرار به طور موقت (تا زمانی که سیستم ذخیره سازی ناموفق بالا برود) ناپدید می شود و عملکرد نوشتن دو برابر افزایش می یابد. پس از راه اندازی مجدد LUN های سیستم ذخیره سازی ناموفق در سیستم ذخیره سازی کار، این افزایش دو برابری به دلیل وجود بارگیری از LUN های یک سیستم ذخیره سازی دیگر از بین می رود و به همان سطح عملکردی که قبل از "سقوط"، اما فقط در همان پلت فرم.
با کمک اندازه مناسب می توان شرایطی را فراهم کرد که در آن کاربران به هیچ وجه خرابی کل سیستم ذخیره سازی را احساس نکنند. اما یک بار دیگر، این نیاز به اندازه گیری بسیار دقیق دارد، که، اتفاقا، می توانید به صورت رایگان با ما تماس بگیرید :-).
راه اندازی مجموعه مترو
راه اندازی یک کلاستر مترو بسیار شبیه به راه اندازی تکرار منظم است که در آن توضیح دادیم . پس بیایید فقط روی تفاوت ها تمرکز کنیم. ما یک نیمکت در آزمایشگاه بر اساس معماری بالا، فقط در حداقل نسخه راه اندازی کردیم: دو سیستم ذخیره سازی متصل از طریق اترنت 10G به یکدیگر، دو سوئیچ 10G و یک میزبان که از طریق سوئیچ ها به هر دو سیستم ذخیره سازی با پورت های 10G نگاه می کند. داور روی یک ماشین مجازی اجرا می شود.
هنگام پیکربندی IP مجازی (VIP) برای یک ماکت، باید نوع VIP - برای یک کلاستر مترو را انتخاب کنید.
دو پیوند تکراری برای دو LUN ایجاد کرد و آنها را روی دو سیستم ذخیره سازی توزیع کرد: LUN TEST Primary در Storage1 (اتصال METRO)، LUN TEST2 Primary برای Storage2 (اتصال METRO2).
برای آنها، ما دو هدف یکسان را پیکربندی کردیم (در مورد ما، iSCSI، اما FC نیز پشتیبانی می شود، منطق پیکربندی یکسان است).
ذخیره سازی 1:
ذخیره سازی 2:
برای پیوندهای تکراری، نگاشتها روی هر سیستم ذخیره سازی انجام شد.
ذخیره سازی 1:
ذخیره سازی 2:
چند مسیری را راه اندازی کردیم و به هاست ارائه کردیم.
راه اندازی داور
شما نیازی به انجام کار خاصی با خود داور ندارید، فقط باید آن را در سایت سوم روشن کنید، IP آن را تنظیم کنید و دسترسی به آن را از طریق ICMP و SSH پیکربندی کنید. پیکربندی خود از خود سیستم های ذخیره سازی انجام می شود. در عین حال، کافی است یک بار آربیتر را روی هر یک از کنترلرهای ذخیره سازی در مترو کلاستر پیکربندی کنید، این تنظیمات به طور خودکار در بین تمام کنترلرها توزیع می شود.
زیر Remote Replication>> Metrocluster (در هر کنترلری)>> دکمه پیکربندی.
IP آربیتر و همچنین رابط های کنترلی دو کنترلر ذخیره سازی از راه دور را وارد می کنیم.
پس از آن، باید تمام خدمات را فعال کنید (دکمه "همه چیز را مجددا راه اندازی کنید"). اگر در آینده پیکربندی مجدد انجام دهید، برای اعمال تنظیمات باید سرویس ها مجددا راه اندازی شوند.
ما بررسی می کنیم که همه سرویس ها در حال اجرا هستند.
این کار راه اندازی متروکلاستر را تکمیل می کند.
تست تصادف
تست خرابی در مورد ما بسیار ساده و سریع خواهد بود، زیرا عملکرد تکرار (سوئیچینگ، سازگاری و غیره) در نظر گرفته شده است. . بنابراین، برای آزمایش قابلیت اطمینان خوشه مترو، کافی است اتوماسیون تشخیص تصادف، سوئیچینگ و عدم تلفات نوشتن (توقف I/O) را بررسی کنیم.
برای انجام این کار، پس از شروع کپی کردن یک فایل بزرگ در یک LUN، که باید در سیستم ذخیره‌سازی دیگری فعال شود، با خاموش کردن فیزیکی هر دو کنترل‌کننده آن، شکست کامل یکی از سیستم‌های ذخیره‌سازی را شبیه‌سازی می‌کنیم.
یک سیستم ذخیره سازی را غیرفعال کنید. در سیستم ذخیره سازی دوم، هشدارها و پیام هایی را در لاگ ها مشاهده می کنیم که ارتباط با سیستم همسایه از بین رفته است. اگر اعلان‌ها از طریق نظارت SMTP یا SNMP پیکربندی شده باشند، اعلان‌های مناسب برای مدیر ارسال می‌شوند.
دقیقاً 10 ثانیه بعد (در هر دو اسکرین شات مشاهده می شود)، پیوند تکرار METRO (پیوندی که در سیستم ذخیره سازی افتاده Primary بود) به طور خودکار در سیستم ذخیره سازی کار به Primary تبدیل شد. با استفاده از نقشه برداری موجود، LUN TEST در دسترس میزبان باقی ماند، ضبط کمی کاهش یافت (در 10 درصد وعده داده شده)، اما متوقف نشد.
آزمون با موفقیت به پایان رسید.
خلاصه کردن
اجرای فعلی متروکلاستر در سیستم‌های ذخیره‌سازی سری N AERODISK Engine به طور کامل به شما امکان میدهد تا مشکلاتی را که نیاز به حذف یا به حداقل رساندن خرابی خدمات فناوری اطلاعات دارید حل کنید و از عملکرد آنها در حالت 24/7/365 با حداقل هزینه‌های نیروی کار اطمینان حاصل کنید.
البته می توانید بگویید که همه اینها تئوری است، شرایط آزمایشگاهی ایده آل و غیره... اما ما تعدادی پروژه اجرا شده داریم که در آنها عملکرد بازیابی فاجعه را پیاده سازی کرده ایم و سیستم ها به خوبی کار می کنند. یکی از مشتریان نسبتاً شناخته شده ما، که در آن فقط از دو سیستم ذخیره سازی در پیکربندی مقاوم در برابر فاجعه استفاده می شود، قبلاً با انتشار اطلاعات مربوط به پروژه موافقت کرده است، بنابراین در قسمت بعدی در مورد اجرای مبارزه صحبت خواهیم کرد.
با تشکر، منتظر یک بحث سازنده هستیم.
منبع: www.habr.com