پیاده سازی خوشه ذخیره‌سازی vSphere Metro با ActiveCluster
برنامه‌های کاربردی تجاری مهم و ماشین‌های مجازی میزبان آن‌ها اغلب به بالاترین انعطاف‌پذیری ممکن نیاز دارند تا اطمینان حاصل شود که عملیات تجاری در صورت وقوع اختلال متوقف نمی‌شود – چه محلی و چه در سطح کل سایت. برای اطمینان از این امر، داده‌های مورد استفاده توسط آن برنامه‌ها باید در دو آرایه، اغلب در بیش از یک مکان جغرافیایی پخش شوند. مهم‌تر از همه، این داده‌ها باید در هر دو سایت به طور همزمان در دسترس باشند. برای دستیابی به این هدف، برخی از آرایه‌ها همانندسازی (تکرار) همزمان را ارائه می‌کنند که توانایی نوشتن همزمان در همان حجم ذخیره‌سازی بلوک را با حفظ نظم نوشتن فراهم می‌کنند. این به طور سنتی تکرار فعال-فعال (Active-Active replication) نامیده می‌شود.
Pure Storage Flash Array راهکار تکرار فعال-فعال خود را به نام ActiveCluster را در نسخه Purity 5.0.0 معرفی کرد. در محیط‌های VMware vSphere، یک مورد معمول برای استفاده از تکرار Active-Active، پیشنهاد VMware vSphere High Availability است. این راهکار VMware vSphere Metro Storage Cluster (vMSC) نامیده می‌شود. ترکیبی از این ویژگی‌ها بهترین Recovery Time Objective (RTO) و Recovery Point Objective (RPO) را برای محیط‌های vSphere فراهم می‌کند.
این مقاله پیکربندی و بهترین روش‌ها را برای استفاده از ویژگی Pure Storage FlashArray ActiveCluster با راهکار VSphere Metro Storage Cluster بررسی می‌کند.
بررسی اجمالی و معرفی راهکار
قوی‌ترین، انعطاف پذیرترین و خودکارترین راهکار برای حفاظت از داده‌های حیاتی و حفظ در دسترس بودن، سه فناوری را ترکیب می‌کند:
- VMware vSphere High Availability: ویژگی vCenter VMware برای راه اندازی مجدد خودکار ماشین‌های مجازی پس از قطع شدن سرویس هاست به یک VMware ESXi دیگر.
- Pure Storage FlashArray ActiveCluster: یک راهکار تکثیر ذخیره‌سازی همزمان فعال-فعال ساده و داخلی برای ذخیره‌سازی بلوک FlashArray.
- VMware vSphere Metro Storage Cluster: یک راهکار VMware vCenter که ترکیبی از حافظه فعال-فعال و سرورهای ESXi که در سراسر مناطق جغرافیایی گسترش یافته، در یک خوشه vCenter است.
VMware vSphere High Availability
VMware High Availability (HA) یک فناوری است که نظارت مبتنی بر خوشه را بر ماشین‌های مجازی در حال اجرا بر روی میزبان‌های ESXi ارائه می‌دهد. اگر خرابی حافظه، شبکه یا میزبان رخ دهد، میزبان‌های باقی‌مانده ESXi برای راه‌اندازی مجدد ماشین‌های مجازی آسیب‌دیده در میزبان‌های سالم هماهنگ می‌شوند. از طریق بررسی اطلاعات ارسالی (heartbeat) شبکه و فضای ذخیره‌سازی، میزبان‌های ESXi می‌توانند انواع اختلال یا رویدادهای جداسازی را شناسایی کرده و به آن‌ها پاسخ دهند تا سریع‌ترین بازیابی خودکار ماشین‌های مجازی را ارائه دهند.
VMware HA راهکاری را برای محافظت از برنامه‌های در حال اجرا در داخل ماشین‌های مجازی که تنظیمات خوشه برنامه مبتنی بر HA یا برنامه کاربردی را ارائه نمی‌دهند، در اختیار کاربر می‌گذارد. با این حال، VMware HA استفاده از آن ویژگی‌ها را در صورتی که برنامه‌ها آن‌ها را ارائه می‌دهند، منع نمی‌کند. آن‌ها در واقع می‌توانند مزایای بیشتری را بر روی یکدیگر ارائه دهند، اگرچه بحث مفصل در مورد آن موضوع، خارج از محدوده این مقاله است.
VMware HA از طریق ذخیره‌سازی مشترک امکان پذیر می‌شود. بدون فضای ذخیره‌سازی مشترک، ماشین‌های مجازی و داده‌های آن‌ها توسط میزبان‌های باقی‌مانده قابل مشاهده نیستند و بنابراین یک عملیات راه‌اندازی مجدد به دلیل بروز مشکل، امکان پذیر نیست. به همین دلیل، ارائه فضای ذخیره‌سازی به‌طور یکسان و همزمان برای همه میزبان‌های یک خوشه، بهترین روش عمومی است و این امکان را برای هر میزبانی فراهم می‌کند که هر ماشین مجازی را روی هر میزبان دیگری در خوشه میزبانی کند.
VMware vSphere Metro Storage Cluster
VMware vSphere Metro Storage Cluster (vMSC) یک ویژگی است که کارکرد VMware HA را با فضای ذخیره‌سازی فعال-فعال گسترش می‌دهد. VMware HA، همانطور که در بخش قبل گفته شد، نیاز به ذخیره‌سازی مشترک برای همه میزبان‌ها در یک کلاستر دارد تا در صورت بروز فاجعه، ماشین‌های مجازی راه اندازی مجدد شوند. در حال حاضر VMware فقط از VMFS برای vMSC پشتیبانی می‌کند.
در بسیاری از سناریوها، یک خوشه ممکن است میزبان‌هایی در دو مرکز داده یا مکان‌های جغرافیایی کاملا مجزا داشته باشد. برای اینکه VMware HA یک VM را روی میزبانی در خوشه‌ای که در مرکز داده دیگری است راه اندازی مجدد کند، آن میزبان باید آن فضای ذخیره‌سازی را نیز ببیند. چند گزینه برای رسیدن به این هدف وجود دارد.
سناریو اول: خوشه میزبان دو سایتی، ذخیره‌سازی تک سایتی
امکان اتصال متقابل یک آرایه ذخیره‌سازی در یک مرکز داده به میزبان‌ها در مرکز داده خود و یک مرکز داده دوم وجود دارد. بنابراین، ذخیره‌سازی تنها توسط یک سایت ارائه می‌شود. اگر برق (به عنوان مثال) در سایت B قطع شود، هیچ میزبانی به ذخیره‌سازی دسترسی نخواهد داشت. در نتیجه، پیکربندی ذخیره‌سازی یک سایتی واقعا انعطاف پذیری بیشتری را ارائه نمی‌دهد.
سناریو دوم: خوشه میزبان دو سایتی، ذخیره‌سازی تک سایتی در سایت سوم
گزینه دیگر این است که یک آرایه را در یک سایت سوم قرار دهید و دسترسی به هاست‌های دو سایت دیگر را در آن ذخیره‌سازی فراهم کنید. در حالی که این سناریو مشکلات آشکاری دارد، اصلی ترین مشکل این است که در صورت خرابی آرایه یا پارتیشن شبکه سایت C هیچ راهکاری وجود ندارد. هر یک از این خرابی‌ها باعث از دست دادن دسترسی همه میزبان‌ها می‌شود.
سناریو سوم: خوشه میزبان دو سایت، ذخیره‌سازی دو سایت
گزینه سوم ذخیره‌سازی کشیده (Stretched) است. در این شرایط، یک آرایه ذخیره‌سازی در سایت A و یک آرایه دیگر در سایت B است. هر دو سایت دارای میزبان‌هایی هستند که می‌توانند یک یا هر دو آرایه را ببینند. یک یا چند حجم ذخیره‌سازی در یک آرایه ایجاد می‌شود و یک کپی دقیق همزمان روی آرایه دوم ایجاد می‌شود. همه نوشته‌ها به طور همزمان بین آرایه‌ها منعکس می‌شوند، بنابراین حجم در هر دو سایت یکسان ظاهر می‌شود و می‌توان همزمان از آن خواند و نوشت. اگر میزبان‌ها در دیتاسنتر A از کار بیفتند (یا ذخیره‌سازی، یا کل مرکز داده)، میزبان‌های مرکز داده B می‌توانند بار کاری خود را با استفاده از آرایه در مرکز داده B بر عهده بگیرند. این سناریویی است که در این مقاله مورد بحث قرار خواهد گرفت.
ترکیبی از ذخیره‌سازی کشیده و خوشه‌های کشیده ESXi سطح بسیار بالایی از انعطاف پذیری را برای یک زیرساخت فراهم می‌کند. هنگامی که ویژگی‌های ریکاوری و بازیابی خودکار ارائه شده توسط VMware vSphere HA روی این دو توپولوژی فعال می‌شود، RTO بیشتر از قبل کاهش می‌یابد، زیرا VMware می‌تواند سریع و هوشمندانه به خرابی هاست، ذخیره‌سازی یا سایت واکنش نشان دهد و ماشین‌های مجازی را دوباره آنلاین کند.
معرفی ActiveCluster
Pure Storage® Purity ActiveCluster یک راهکار تکثیر دوطرفه فعال-فعال کاملا متقارن است که همانندسازی همزمان را برای RPO صفر و failover شفاف خودکار را برای RTO صفر فراهم می‌کند. ActiveCluster چندین سایت را در بر می‌گیرد که آرایه‌های خوشه‌ای و میزبان‌های خوشه‌ای را قادر می‌سازد تا برای استقرار تنظیمات مرکز داده فعال-فعال انعطاف پذیر استفاده شوند.
- تکرار همزمان (Synchronous Replication): نوشته‌ها بین آرایه‌ها همگام‌سازی می‌شوند و در RAM غیر فرار (NVRAM) در هر دو آرایه قبل از به اطلاع رسیدن میزبان محافظت می‌شوند.
- Symmetric Active/Active: خواندن و نوشتن در Volume های یکسان در دو طرف آینه، با آگاهی اختیاری میزبان به آرایه سایت.
- Failover شفاف: قابلیت failover بدون اختلال بین آرایه‌ها و سایت‌هایی که به طور همزمان تکرار می‌شوند با همگام‌سازی مجدد و بازیابی خودکار.
- یکپارچه سازی تکرار Async: از async برای کپی‌های پایه و همگام سازی مجدد استفاده می‌کند. روابط ناهمگام را بدون ارسال مجدد داده به همگام سازی تبدیل می‌کند. همگام سازی داده‌ها به سایت سوم برای DR.
- بدون نیاز به سخت‌افزار و مجوز: بدون نیاز به سخت افزار اضافی، بدون نیاز به مجوزهای نرم افزاری پرهزینه، فقط محیط عملیاتی Purity را ارتقا دهید و قابلیت فعال/فعال را داشته باشید.
- مدیریت ساده: عملیات مدیریت داده را از هر طرف آینه انجام دهید، ذخیره‌سازی فراهم کنید، میزبان‌ها را متصل کنید، تصاویر فوری و کلون‌ها را ایجاد کنید.
- Pure1® Cloud Mediator یکپارچه: میانجی پسیو با پیکربندی خودکار که امکان failover شفاف را فراهم می‌کند و از تقسیم مغزی (Split-brain) بدون نیاز به استقرار و مدیریت مؤلفه دیگر جلوگیری می‌کند.
اجزاء
Purity ActiveCluster از سه جزء اصلی تشکیل شده است: واسطه Pure1، جفت‌های آرایه خوشه‌ای فعال/فعال و کانتینر ذخیره‌سازی کشیده.
- میانجی ابری Pure1: یک جزء ضروری از راهکار است که برای تعیین اینکه کدام آرایه خدمات داده را در صورت قطعی در محیط ادامه خواهد داد، استفاده می‌شود.
- آرایه‌های فلش خوشه‌ای فعال/فعال: از تکرار همزمان برای حفظ یک کپی از داده‌ها در هر آرایه و ارائه آن‌ها به عنوان یک کپی ثابت به میزبان‌هایی که به هر یک یا هر دو آرایه متصل هستند، استفاده می‌کند.
- کانتینر ذخیره‌سازی کشیده: کانتینر مدیریتی که اشیاء ذخیره‌سازی مانند حجم‌ها را در گروه‌هایی جمع آوری می‌کند که بین دو آرایه کشیده شده‌اند.
مدیریت
ActiveCluster یک شی مدیریت جدید را معرفی می‌کند: Podها. یک Pod یا غلاف یک کانتیتر ذخیره‌سازی کشیده (Stretched) است که مجموعه ای از اشیاء را تعریف می‌کند که به طور همزمان با هم تکرار می‌شوند و بین کدام آرایه‌ها تکرار می‌شوند. یک آرایه می‌تواند از چند پاد پشتیبانی کند. پادها می‌توانند تنها روی یک آرایه یا روی دو آرایه به طور همزمان با تکرار همزمان وجود داشته باشند. پادهای کشیده شده بین دو آرایه به پادهایی که به طور همزمان بین دو آرایه تکرار می‌شوند، گفته می‌شود.
پادها می‌توانند شامل حجم‌ها، گروه‌های حفاظتی (برای زمان‌بندی snapshotها و تکرار ناهمزمان) و سایر اطلاعات پیکربندی مانند حجم‌هایی باشند که به کدام میزبان متصل هستند. پاد به‌عنوان یک گروه سازگاری عمل می‌کند و تضمین می‌کند که چندین حجم در یک غلاف به ترتیب نوشتن ثابت می‌مانند.
پادها همچنین فضاهای نام حجمی را ارائه می‌دهند، به این معنی که حجم‌های مختلف ممکن است نام حجم یکسانی داشته باشند اگر در پادهای مختلف باشند. در تصویر بالا، حجم‌ها در pod3 و pod4 حجم‌های متفاوتی نسبت به حجم‌های pod1 دارند، یک غلاف فعال/فعال کشیده. این ویژگی، امکان انتقال بارهای کاری بین آرایه‌ها یا ادغام بارهای کاری از چندین آرایه به یک آرایه را بدون تداخل نام حجم می‌دهد.
میانجی
failover شفاف بین آرایه‌ها در ActiveCluster خودکار است و نیازی به مداخله مدیر ذخیره‌سازی ندارد. Failover در بازه‌های زمانی استاندارد ورودی/خروجی میزبان اتفاق می‌افتد، مشابه روشی که failover بین دو کنترل‌کننده در یک آرایه در طول ارتقای سخت‌افزار یا نرم‌افزار بدون اختلال رخ می‌دهد.
ActiveCluster طراحی شده است تا حداکثر در دسترس بودن را در میان آرایه‌های ذخیره‌سازی فعال/فعال متقارن فراهم کند و در عین حال از بروز وضعیت split-brain جلوگیری کند. split-brain موردی است که در آن دو آرایه ممکن است I/O را به همان حجم ارائه دهند، بدون اینکه داده‌ها بین دو آرایه هماهنگ باشند.
هر راهکار تکثیر همزمان فعال/فعال که برای ارائه در دسترس بودن مستمر در دو سایت مختلف طراحی شده است، نیازمند یک مؤلفه است که به عنوان شاهد یا رأی دهنده نامیده می‌شود تا ضمن جلوگیری از split-brain، میانجی failover باشد. ActiveCluster شامل یک روش ساده برای استفاده، سبک وزن و خودکار برای برنامه‌ها برای failover شفاف یا جابجایی ساده بین سایت‌ها در صورت خرابی بدون دخالت کاربر به نام Pure1 Cloud Mediator است.
Pure1 Cloud Mediator مسئول اطمینان از این است که فقط یک آرایه مجاز است زمانی که ارتباط بین آرایه‌ها قطع می‌شود، برای هر پاد فعال بماند. در صورتی که آرایه‌ها دیگر نتوانند از طریق اتصال تکراری با یکدیگر ارتباط برقرار کنند، هر دو آرایه ورودی/خروجی را متوقف می‌کنند و به میانجی رجوع می‌کنند تا مشخص کند کدام آرایه می‌تواند برای هر پاد همگام‌سازی شده فعال بماند. به این می‌گویند مسابقه تا میانجی. اولین آرایه‌ای که به میانجی می‌رسد مجاز است غلاف‌های تکرار شده همزمان خود را آنلاین نگه دارد. آرایه دوم برای رسیدن به میانجی باید سرویس I/O را به حجم‌های همزمان تکرار شده خود متوقف کند تا از split-brain جلوگیری شود. کل عملیات در بازه‌های زمانی استاندارد ورودی/خروجی میزبان انجام می‌شود تا اطمینان حاصل شود که برنامه‌ها بیش از یک مکث و از سرگیری I/O را تجربه نمی‌کنند.
میانجی ابری Pure1
یک میانجی failover باید در یک سایت سوم قرار داشته باشد که در یک دامنه شکست مجزا از هر سایتی که آرایه‌ها در هستند، قرار دارد. هر سایت آرایه باید اتصال شبکه مستقل به واسطه داشته باشد به طوری که یک قطعی شبکه منفرد مانع از دسترسی هر دو آرایه به واسطه نشود. یک میانجی همچنین باید یک جزء بسیار سبک و آسان برای اداره راهکار ارائه دهد. راهکار Pure Storage با استفاده از یک میانجی مبتنی بر ابر یکپارچه این قابلیت را به طور خودکار فراهم می‌کند. Pure1 Cloud Mediator دو عملکرد اصلی را ارائه می‌دهد:
- از بروز وضعیت split-brain که در آن هر دو آرایه به طور مستقل اجازه دسترسی به داده‌ها را بدون همگام سازی بین آرایه‌ها می‌دهند، جلوگیری می‌کند.
- تعیین می‌کند که در صورت خرابی آرایه، قطع لینک تکراری یا قطع شدن سایت، کدام آرایه به سرویس ورودی/خروجی به حجم‌های همزمان تکرار شده ادامه می‌دهد.
میانجی ابری Pure1 دارای مزایای زیر نسبت به یک رای دهنده یا مؤلفه شاهد غیر خالص معمولی است:
- مزایای عملیاتی SaaS: مانند هر راهکار SaaS، پیچیدگی تعمیر و نگهداری عملیاتی حذف می‌شود. هیچ چیزی برای نصب در محل وجود ندارد، بدون سخت افزار یا نرم افزار برای نگهداری، عدم نیاز به پیکربندی و پشتیبانی از HA، بدون به روز رسانی وصله امنیتی و موارد دیگر.
- بهره‌مندی از سایت سوم به صورت خودکار: میانجی ابری Pure1 ذاتا در یک دامنه شکست جداگانه از هر یک از دو آرایه است.
- پیکربندی خودکار: آرایه‌های پیکربندی شده برای تکرار همزمان به طور خودکار به واسطه ابری Pure1 متصل می‌شوند و از آن استفاده می‌کنند.
- بدون پیکربندی نادرست: با پیکربندی خودکار و پیش فرض، هیچ خطری وجود ندارد که پیکربندی میانجی نادرست باشد.
- بدون مداخله انسانی: تعداد قابل توجهی از مسائل در راهکارهای تکثیر همزمان فعال/فعال غیر خالص، به ویژه مواردی که مربوط به brain-split تصادفی است، به خطای انسانی مربوط می‌شود. میانجی غیرانسانی خودکار Pure خطای اپراتور را از معادله حذف می‌کند.
- میانجیگری غیرفعال: دسترسی مداوم به واسطه برای عملیات عادی لازم نیست. آرایه‌ها وضعیت ارتباط خود را با واسطه حفظ می‌کنند، اما اگر آرایه‌ها ارتباط خود را با واسطه قطع کنند، تا زمانی که پیوند تکرار فعال است، به تکثیر همزمان و ارائه داده‌ها ادامه می‌دهند.
In-Premises Failover Mediator
میانجیگری Failover برای ActiveCluster همچنین می‌تواند با استفاده از یک میانجی داخلی که به‌عنوان یک فایل OVF توزیع شده و به‌عنوان یک VM مستقر شده است، ارائه شود. رفتارهای Failover دقیقا همان چیزی است که در بالا توضیح داده شد. میانجی داخلی به سادگی نقش میانجی ابری Pure1 را در حین رویدادهای failover بازی می‌کند.
میانجی داخلی دارای الزامات اساسی زیر است:
- میانجی داخلی فقط می‌تواند به عنوان یک VM روی سخت‌افزار مجازی‌سازی شده مستقر شود. به عنوان یک برنامه مستقل قابل نصب نیست.
- دسترسی بالا برای میانجی باید توسط میزبانی که میانجی در آن مستقر است ارائه شود. به عنوان مثال، با استفاده از VMware HA یا Microsoft Hyper-V HA Clustering.
- ذخیره‌سازی میانجی نباید اجازه دهد که پیکربندی میانجی به نسخه‌های قبلی بازگردد. این برای موقعیت‌هایی مانند بازیابی snapshot ذخیره‌سازی، یا مواردی که ممکن است میانجی در حافظه آینه‌ای ذخیره شود، اعمال می‌شود.
- آرایه‌ها باید طوری پیکربندی شوند که از میانجی داخلی به جای میانجی ابری Pure1 استفاده کنند.
- میانجی باید در یک سایت سوم، در یک دامنه شکست جداگانه مستقر شود که در هیچ یک از سایت‌هایی که آرایه‌ها نصب شده‌اند، تحت تأثیر خرابی‌ها قرار نگیرد.
- هر دو سایت آرایه باید اتصالات شبکه مستقلی به میانجی داشته باشند به طوری که خرابی یک اتصال شبکه مانع از دسترسی هر دو آرایه به میانجی نشود.
Pre-election
Pre-Election یک ویژگی ActiveCluster است که هنگامی که هر دو FlashArray اتصال به میانجی را از دست می‌دهند به طور خودکار درگیر می‌شود تا اطمینان حاصل شود که در صورت از دست دادن پیوندهای تکراری، حجم‌های پاد کشیده آنلاین باقی می‌مانند.
الزامات Pre-Election چیست؟
این قابلیت به طور پیش فرض در Purity 5.3.x و نسخه‌های بالاتر فعال است.
Pre-election چه می‌کند؟
پس از اینکه هر دو FlashArray تشخیص دادند که میانجی در دسترس نیست، Pre-Election این کارها را انجام می‌دهد:
- حصول اطمینان از این که آرایه از پیش انتخاب شده در پاد، در صورت از کار افتادن شبکه تکرار، آنلاین خواهد ماند.
- حصول اطمینان از این که آرایه از پیش انتخاب شده در پاد، در صورت خرابی آرایه غیرانتخابی، آنلاین خواهد ماند.
- در صورت تنظیم، FlashArray برنده را برای هر پاد بر اساس ترجیح failover پاد تعیین می‌کند، در غیر این صورت یک FlashArray انتخاب می‌کند.
پس از اینکه یک (یا هر دو) FlashArray تشخیص داد که میانجی در دسترس است، Pre-Election غیرفعال می‌شود و به رفتار failover شفاف استاندارد ActiveCluster باز می‌گردد.
Pre-election چه کاری انجام نمی دهد؟
Pre-election این کارها را انجام نمی‌دهد:
- نادیده گرفتن رفتار عادی: اگر یک آرایه هنوز به میانجی دسترسی داشته باشد، باید برای آنلاین ماندن و دسترسی به میانجی رقابت کند.
- ارائه یک ترجیح failover سخت.
- اگر آرایه از پیش انتخاب شده با شکست مواجه شود، طرف غیر منتخب را اجبارا آنلاین کند.
- اگر هم شبکه میانجی و هم شبکه تکثیر همزمان از کار بیفتند، پاد را آنلاین نگه دارد.
دسترسی یکنواخت و غیر یکنواخت
هاست‌ها را می‌توان طوری پیکربندی کرد که فقط آرایه‌ای را که برای آن محلی محسوب می‌شود یا هر دو آرایه را مشاهده کند. گزینه اول vMSC غیر یکنواخت نامیده می‌شود، دومی به عنوان vMSC یکنواخت شناخته می‌شود.
یک مدل دسترسی یکنواخت به ذخیره‌سازی می‌تواند در محیط‌هایی استفاده شود که در آن اتصال میزبان به آرایه FC یا اترنت (برای SCSi) و اتصال اترنت آرایه به آرایه بین دو سایت وجود دارد. هنگامی که سیستم به این روش مستقر می‌شود، یک میزبان به همان حجم از طریق آرایه محلی و آرایه راه دور دسترسی دارد. این راهکار از اتصال آرایه‌ها با تأخیر ۱۱ میلی‌ثانیه زمان رفت و برگشت (RTT) بین آرایه‌ها پشتیبانی می‌کند.
تصویر بالا نشان دهنده مسیرهای منطقی بین میزبان‌ها و آرایه‌ها و ارتباط تکرار بین دو آرایه در یک مدل دسترسی یکنواخت است. از آنجایی که یک مدل دسترسی یکنواخت به ذخیره‌سازی به همه هاست‌ها، صرف نظر از مکان سایت، اجازه می‌دهد تا به هر دو آرایه دسترسی داشته باشند، مسیرهایی با ویژگی‌های تأخیر متفاوت وجود خواهد داشت. مسیرهای میزبان به آرایه محلی تأخیر کمتری خواهند داشت. مسیرهای هر میزبان محلی به آرایه راه دور دارای تأخیر بالاتری خواهند بود.
برای بهترین عملکرد در محیط‌های تکثیر همزمان فعال/فعال، میزبان‌ها باید از استفاده از مسیرهایی که به آرایه راه دور دسترسی دارند، مگر در موارد ضروری، جلوگیری شود. به عنوان مثال، در تصویر زیر اگر VM 2A یک عملیات نوشتن روی حجم A روی اتصال سمت میزبان به آرایه A انجام دهد، آن نوشتن ۲ برابر تاخیر پیوند بین سایتی را متحمل می‌شود، ۱ تاخیر برای هر عبور از شبکه. این عملیات برای سفر از میزبان B به آرایه A ۱۱ میلی‌ثانیه تأخیر را تجربه می‌کند و ۱۱ میلی‌ثانیه تأخیر دیگر را در حالی که آرایه A به‌طور همزمان عملیات نوشتن را به آرایه B می‌فرستد، تجربه می‌کند.
با Pure Storage Purity ActiveCluster، چنین دردسرهای مدیریتی وجود ندارند. ActiveCluster از ALUA استفاده می‌کند تا مسیرها را به میزبان‌های محلی به‌عنوان مسیرهای فعال/بهینه‌سازی شده و مسیرها را برای میزبان‌های راه دور به‌عنوان فعال/غیر بهینه‌سازی شده نشان دهد. با این حال، دو مزیت در پیاده سازی ActiveCluster وجود دارد.
- در ActiveCluster، حجم‌های موجود در پادهای کشیده در هر دو آرایه به صورت read/write می‌شوند. چیزی به نام یک حجم غیرفعال وجود ندارد که نتواند هم خواندن و هم نوشتن را ارائه دهد.
- مسیر بهینه شده بر اساس اتصال میزبان به حجم با استفاده از گزینه آرایه ترجیحی تعریف می‌شود. این تضمین می‌کند که صرف نظر از میزبانی که یک VM یا برنامه بر روی آن در حال اجرا است، یک مسیر بهینه شده محلی برای آن حجم خواهد داشت.
ActiveCluster دیتاسنترهای واقعا فعال/فعال را در دسترس قرار می‌دهد و نگرانی در مورد اینکه یک VM در چه سایت یا میزبانی اجرا می‌شود را از بین می‌برد. VM همیشه بدون توجه به سایت، عملکرد یکسانی خواهد داشت. در حالی که یک VM 1A روی میزبان A اجرا می‌شود و به حجم A دسترسی دارد، فقط از مسیرهای بهینه سازی شده محلی همانطور که در تصویر بعدی نشان داده شده است استفاده می‌کند.
اگر VM یا برنامه کاربردی به میزبانی در سایت دیگر سوئیچ شود، در حالی که داده‌ها در جای خود باقی مانده‌اند، فقط مسیرهای محلی در سایت دیگر همانطور که در تصویر بعدی نشان داده شده است استفاده می‌شود. برای اطمینان از دسترسی بهینه محلی، نیازی به تنظیم اولویت‌های مسیر یا انتقال داده‌ها به حجم متفاوتی نیست.
دسترسی غیر یکنواخت
یک مدل دسترسی غیر یکنواخت به ذخیره‌سازی در محیط‌هایی استفاده می‌شود که در آن اتصال میزبان به آرایه FC یا اترنت (برای iSCSI)، فقط به صورت محلی در همان سایت وجود دارد. اتصال اترنت برای اتصال تکراری آرایه به آرایه همچنان باید بین دو سایت وجود داشته باشد. هنگامی که سیستم به این روش مستقر می‌شود، هر میزبان فقط از طریق آرایه محلی و نه آرایه راه دور به یک حجم دسترسی دارد. این راه‌حل از اتصال آرایه‌ها با تأخیر ۱۱ میلی‌ثانیه زمان رفت و برگشت (RTT) بین آرایه‌ها پشتیبانی می‌کند.
میزبان‌ها ورودی/خروجی‌ها را فقط در تمام مسیرهای ذخیره‌سازی توزیع می‌کنند، زیرا فقط مسیرهای محلی Active/Optimized در دسترس هستند.
واژه نامه اصطلاحات ActiveCluster
عبارات زیر به طور مکرر در این مقاله که برای معرفی ActiveCluster بود، استفاده شده‌اند:
Pod: یک pod یک فضای نام و یک گروه سازگاری است. تکثیر همزمان را می‌توان در یک پاد فعال کرد، که باعث می‌شود تمام volumeهای آن پاد در هر دو FlashArray در پاد وجود داشته باشد.
Stretching: کشش یک پاد، عمل اضافه کردن یک FlashArray دوم به یک پاد است. وقتی به آرایه دیگری کشیده می‌شود، داده‌های volume شروع به همگام‌سازی می‌کنند و پس از تکمیل، تمام volumeهای پاد در هر دو FlashArray در دسترس خواهند بود.
Unstretching :unstretching یک پاد عمل حذف FlashArray از یک پاد است. این کار از طریق FlashArray قابل انجام است. وقتی حذف شد، volumeها و خود پاد دیگر در FlashArray حذف شده در دسترس نیستند.
Restretching: هنگامی که یک پاد کشیده نشده است، آرایه دیگر (آرایه کشیده نشده) یک کپی از پاد را به مدت ۲۴ ساعت در انتظار ریشه کنی نگه می‌دارد. این به پاد اجازه می‌دهد تا به سرعت بدون نیاز به ارسال مجدد همه داده‌ها در صورت بازگردانی قبل از تکمیل ریشه‌کنی در ۲۴ ساعت مجددا کشیده شود.
