Ми вже чимало писали про EMC VPLEX ( тут , тут і тут ) - вирішенні для віртуалізації мережі зберігання даних SAN, яке дозволяє об'єднати ресурси різних дискових масивів різних виробників в єдиний логічний пул на рівні датацентру або декількох географічно рознесених датацентров. Це дозволяє гнучко підходити до розподілу дискового простору і здійснювати централізований моніторинг і контроль дискових ресурсів.
Тепер компанії EMC і VMware випустили відеоролик, що розкриває переваги спільного використання цих двох рішень:
У ролику показується, що VPLEX і Nicira мають високу ступінь інтеграції в рамках загальної концепції автоматизованого датацентру. Наприклад, при збільшенні трафіку реплікації продукт Nicira адаптивно реагує на цю подію і збільшує доступну смугу пропускання для VPLEX при зростанні навантаження, а також зменшує смугу при її падінні. Це особливо актуально в географічно рознесених датацентрах з обмеженими каналами і високими вимогами по доступності додатків.
Таги: EMC, VPLEX, Nicira, NVP, SDN, VXLAN, SAN, NSX, Enterprise
З 21 по 24 травня проводилася конференція EMC World 2012, де однією з головних тем були, звичайно ж, рішення щодо захисту даних і балансування навантаження між географічно розподіленими датацентрами. Перш за все були анонсовані рішення EMC VPLEX 5.1 і RecoverPoint 3.5 :
Як і раніше, SRA-адаптера для спільного вирішення VMware SRM + VPLEX досі немає, тому як, схоже, немає остаточної ясності, чи потрібен SRM, коли є VPLEX Metro з синхронізованими томами між датацентрами і "Розтягнутий кластер" VMware vMSC (VSphere Metro Storage Cluster) між хостами датацентров. Безумовно, співробітники EMC кажуть, що рішення взаємодоповнюючі (тому що SRM - це план відновлення після збоїв, а не схема катастрофостійкості), але поки SRM пропонується використовувати тільки в схемі з рішенням для захисту даних EMC RecoverPoint, для якого SRA-адаптер вже є:
На цю тему з'явився окремий документ " Improving VMware Disaster Recovery with EMC RecoverPoint ".
З'явилася також підтримка рознесених active / active кластерів Oracle RAC в EMC VPLEX:
З точки зору vSphere Metro Storage Cluster також з'явилася пара цікавих новин. По-перше, документ " VMware vSphere Metro Storage Cluster Case Study ", Опісиваещій різні сценарії відмов в розтягнутому кластері високої доступності (vMSC), побудованому між двома географічно рознесеними майданчиками:
Також нагадаємо про документ " Stretched Clusters and VMware vCenter Site Recovery Manager ", Який допоможе зрозуміти, в яких ситуаціях знадобиться розтягнутий кластер, а коли без SRM не обійтися.
По-друге, до програми сертифікації vSphere Metro Storage Cluster program приєдналася HP Lefthand:
Більш докладно про це можна прочитати в KB 2020097 або в документі " Implementing VMware vSphere Metro Storage Cluster with HP LeftHand Multi-Site storage ". У HCL компанії VMware рішення HP Lefthand з'явилося в категорії "iSCSI vSphere Metro Cluster Storage".
Ну і для тих, кому цікаво, про що ще говорили на EMC World, можна почитати тут і тут .
Таги: VMware, vSphere, VPLEX, HA, vMSC, ESXi, EMC
Ми вже писали про рішення EMC VPLEX , Яке дозволяє організувати катастрофостійкі архітектуру сховищ для віртуальних машин за рахунок організації синхронного розподіленого віртуального томи (Disrtibuted Virtual Volume).
Сімейство продуктів EMC VPLEX з операційною системою EMC GeoSynchrony є рішенням по об'єднанню на основі мережі SAN. Технологія EMC VPLEX Metro дозволяє об'єднати дискові ресурси масивів, які перебувають на двох географічно розділених майданчиках в єдиний пул зберігання. З боку серверів ESX / ESXi на обох майданчиках доступний один віртуальний логічний тому, який має властивість катастрофостійкості, оскільки дані фізично зберігаються і синхронізуються на обох майданчиках.
Дана технологія інтегрована з технологією відмовостійкості VMware HA за рахунок підтримки структури vSphere Metro Storage Cluster , Що дозволяє використовувати їх спільно для обробки різних варіантів збоїв у віртуальній інфраструктурі. До того ж, EMC VPLEX - це єдине сертифіковане VMware рішення для організації географічно "розтягнутих" кластерів VMware HA.
У географічно рознесених ЦОД, сховища яких синхронізовані за допомогою VPLEX, є важлива проблема - чи є порушення зв'язку між вузлами кластерів VPLEX наслідком збою мережі або збою на майданчику. Вона зачіпає і кластери VPLEX, які знаходяться в різних географічних точках. Система EMC VPLEX обробляє збій мережі шляхом автоматичного припинення всіх операцій введення-виведення в пристрої ( «відключення») на одній з двох майданчиків в залежності від набору преопределенность правил. Операції введення-виведення в той же пристрій на іншому майданчику продовжують виконуватися в звичайному режимі. Оскільки правила застосовуються до кожного пристрою окремо, в разі поділу мережі активні пристрої можуть бути присутніми на обох майданчиках. Для запобігання цьому використовується Cluster Witness - компонент на сторонньої майданчику, який відповідає за моніторинг доступності основної та резервної площадки.
При відмові різних компонентів ІТ-інфраструктури та каналів зв'язку можуть виникнути різні ситуації як для кластера VPLEX, так і для кластера VMware HA, які успішно обробляються і теоретично досить мало ситуацій, які можуть привести до втрати даних. Однак є ситуації (і вони завжди будуть в розподілених ЦОД - саме тому RTO = 0 це Objective, а не Requirement), коли не можна автоматизувати операції по відновленню і потрібне втручання адміністратора, який виконає найбільш правильне дію.
Ось як VPLEX спільно з HA обробляють різні варіанти збоїв:
Сценарій Поведінка VPLEX Вплив на кластер VMware HA Відмова одного з шляхів порту VPLEX back-end (BE) до дискового масиву. VPLEX прозоро переключиться на альтернативний шлях, без впливу на роботу розподілених віртуальних томів (Distributed Virtual Volumes). Відсутнє. Відмова одного з шляхів до порту VPLEX front-end (FE) від хост-сервера. Сервер ESXi за рахунок вбудованого механізму роботи по декількох шляхах переключиться на резервний шлях до розподілених віртуальним томів. Відсутнє. Вихід з ладу масиву на основному майданчику. VPLEX продовжить обслуговувати віртуальні томи, використовуючи дисковий масив резервний майданчик. Коли основний дисковий масив відновиться після збою, тому основного дискового масиву будуть автоматично синхронізовані з резервного. Відсутнє. Вихід з ладу масиву на резервному майданчику. VPLEX продовжить обслуговувати віртуальні томи, використовуючи дисковий масив основного майданчика. Коли резервний дисковий масив відновиться після збою, тому резервного дискового масиву будуть автоматично синхронізовані з основного. Відсутнє. Вихід з ладу одного з пристроїв VPLEX Director. VPLEX продовжить обслуговувати віртуальні томи, перенаправивши запити на інші директори кластера VPLEX. Відсутнє. Повна втрата основного майданчика (катастрофа), включаючи всі хости ESXi і компоненти кластера VPLEX (виявляється за допомогою Cluster Witness). VPLEX продовжить обслуговувати запити вводу-виводу на дисковому масиві резервний майданчик. Коли основна площадка відновиться, віртуальні томи будуть синхронізовані з резервний майданчик. Віртуальні машини основного майданчика будуть перезапущени на хостах резервний майданчик. Повна втрата резервний майданчик (катастрофа), включаючи всі хости ESXi і компоненти кластера VPLEX (виявляється за допомогою Cluster Witness). VPLEX продовжить обслуговувати запити вводу-виводу на дисковому масиві основного майданчика. Коли резервна площадка відновиться, віртуальні томи будуть синхронізовані з основного майданчика. Віртуальні машини резервний майданчик будуть перезапущени на хостах основного майданчика. Множинний вихід з ладу хост-серверів в рамках однієї з майданчиків. Відсутня Механізм VMware HA перезапустить віртуальні машини на що залишилися хостах кластера HA. Вихід з ладу мережі сигналів доступності в рамках однієї з майданчиків. Відсутнє. HA продовжить обмін сигналами доступності через загальні сховища (див. тут ), Що не спричинить за собою аварійного відновлення. Всі шляхи до хосту ESXi знаходяться в стані APD (All Paths down) - тобто тимчасово не маєте доступу до сховищ (віртуальним томів). Відсутнє. В цьому випадку необхідно перезапустити сервер ESXi, що призведе до перезапуску віртуальних машин в кластері HA на інших хост-серверах кластера HA. Розрив каналу реплікації між пристроями VPLEX при збереженні мережі управління. На резервному майданчику VPLEX переводить віртуальні томи в режим I / O Failure (що забороняє роботу з ними). На основному майданчику віртуальні томи продовжують залишатися доступними віртуальним машинам. На основному майданчику віртуальні машини продовжують функціонувати. На резервному майданчику віртуальні машини отримують помилку введення-виведення і вимикаються. Механізм VMware HA (VM Monitoring) відновлює їх на резервному майданчику. Збій кластера VPLEX (компоненти кластера на обох майданчиках недоступні, але хости ESXi не відчувають проблем роботи по SAN і СПД). Запити введення-виведення для всіх віртуальних томів продовжать обслуговуватися на основному майданчику. Хости ESXi на резервному майданчику перейдуть в стан APD. Це зажадає їх перезавантаження для відновлення віртуальних машин. Одночасний повний вихід з ладу обох майданчиків. Після відновлення майданчиків VPLEX продовжить обслуговувати запити вводу-виводу (в першу чергу слід запустити дискові масиви на обох майданчиках). Хости ESXi повинні бути включені тільки після того, як компоненти VPLEX будуть відновлені, а віртуальні томи синхронізовані. При включенні хостів ESXi віртуальні машини будуть відновлені механізмом VMware HA. Вихід з ладу одного з директорів VPLEX на одному з майданчиків, а також вихід дискового масиву на протилежній площадці (резервна площадка для віртуального томи). Решта директори кластера VPLEX продовжать обслуговувати доступ до віртуальних томів, використовуючи дисковий масив, який є для них основним. Відсутня Розрив мережі сигналів доступності (heartbeat) на одному з майданчиків і розрив комунікацій VPLEX між майданчиками (відміну від виходу з ладу майданчики розуміє Cluster Witness). VPLEX припиняє обслуговувати запити вводу-виводу для віртуальних томів, у яких дискові масиви позначені як резервні. Обмін продовжиться тільки з дисковими масивами, які є основними для віртуальних томів. На основному майданчику віртуальні машини продовжать виконуватися. Для VMware HA - це ситуація «split-brain» (хости резервний майданчик вважають себе залишилися працездатними в кластері і намагаються включити віртуальні машини). При включенні ВМ на хостах резервний майданчик буде отримана помилка введення-виведення. У цій ситуації необхідно вручну перереєструвати віртуальні машини резервний майданчик на основний. Том VPLEX виявляється недоступний (наприклад, випадково видалений з консолі управління). VPLEX продовжить обслуговувати запити вводу-виводу з резервний майданчик, де те доступний. Всі хости ESXi працюють з томом VPLEX отримують помилку введення-виведення і переходять в стан PDL (Permanent Device Loss) . В результаті компонент VM Monitoring зупиняє віртуальні машини, після чого вони запускаються на хостах іншого майданчика. Розрив з'єднання між компонентами VPLEX на обох майданчиках і одночасних вихід з ладу з'єднання VPLEX Cluster Witness до основному майданчику. VPLEX припиняє обслуговувати запити вводу-виводу до віртуальних томів на резервному майданчику і продовжує роботу з томами основного майданчика. Віртуальні машини на резервному майданчику завершать роботу помилково введення-виведення, вони можуть бути вручну зареєстровані і запущені на резервному майданчику. Розрив з'єднання між компонентами VPLEX на обох майданчиках і одночасних вихід з ладу з'єднання VPLEX Cluster Witness до основному майданчику. VPLEX припиняє обслуговувати запити вводу-виводу до віртуальних томів на основному майданчику і продовжує роботу з томами резервний майданчик. Віртуальні машини на основному майданчику завершать роботу помилково введення-виведення, вони можуть бути вручну зареєстровані і запущені на резервному майданчику. Збій компонента VPLEX Cluster Witness. VPLEX продовжує обслуговувати запити вводу-виводу на обох майданчиках. Відсутнє. Збій компонента VPLEX Management Server на одному з майданчиків. Відсутнє. Відсутнє. Відмова сервера управління віртуальною інфраструктурою VMware vCenter Відсутня. На механізм VMware HA і відновлення віртуальних машин це не вплине. Однак правила розміщення і балансування віртуальних машин по хост-серверів припинять працювати.Як бачите, все ситуації обробляються розумно і коректно. Тут обов'язковим має бути наявність VPLEX Cluster Witness, який відрізнить вихід з ладу лінків між ЦОД від виходу з ладу одного з ЦОД, про що він скаже їм обом.
Також треба відзначити, що повної автоматизації відновлення тут не можна домогтися, як то кажуть, "by design".
Таги: EMC, VPLEX, HA, VMware, vSphere, Cloud
Скоро нам доведеться брати участь в цікавому проекті - побудова "розтягнутого" кластера VMware vSphere 5 на базі технології та обладнання EMC VPLEX Metro з підтримкою можливостей VMware HA і vMotion для відмовостійкості і розподілу навантаження між географічно розподіленими ЦОД.
Взагалі кажучи, рішення EMC VPLEX вельми нове і анонсовано було тільки в минулому році, але зараз для нашого замовника вже їдуть модулі VPLEX Metro і ми будемо будувати active-active конфігурацію ЦОД (відстань невелика - десь 3-5 км) для віртуальних машин .
Для початку EMC VPLEX - це рішення для віртуалізації мережі зберігання даних SAN, яке дозволяє об'єднати ресурси різних дискових масивів різних виробників в єдиний логічний пул на рівні датацентру. Це дозволяє гнучко підходити до розподілу дискового простору і здійснювати централізований моніторинг і контроль дискових ресурсів. Ця технологія називається EMC VPLEX Local:
З фізичної точки зору EMC VPLEX Local являє собою набір VPLEX-директорів (кластер), що працюють в режимі відмовостійкості і балансування навантаження, які представляють собою проміжний шар між SAN підприємства і дисковими масивами в рамках одного ЦОД:
У цьому підході є дуже багато переваг (наприклад, mirroring томів двох масивів на випадок відмови одного з них), але ми на них зупинятися не будемо, оскільки нам набагато цікавіша технологія EMC VPLEX Metro, яка дозволяє об'єднати дискові ресурси двох географічно розділених майданчиків в єдиний пул зберігання (обом майданчикам видно один логічний том), який має властивість катастрофостійкості (і всередині нього на рівні HA - відмовостійкості), оскільки дані фізично зберігаються і синхронізуються на обох майданчиках. У плані VMware vSphere це виглядає так:
Тобто для хост-серверів VMware ESXi, розташованих на двох майданчиках є одне віртуальне сховище (Datastore), тобто той самий Virtualized LUN, на якому вони бачать віртуальні машини, що виконуються на різних майданчиках (тобто режим active-active - різні сервіси на різних майданчиках але на одному сховищі). Хости ESXi бачать VPLEX-директори як таргети, а самі VPLEX-директори є ініціаторами по відношенню до дискових масивів.
Все це забезпечується технологією EMC AccessAnywhere, яка дозволяє працювати хостам в режимі read / write на масиви обох вузлів, тому яких входять в загальний пул віртуальних LUN.
Треба сказати, що технологія EMC VPLEX Metro підтримується на відстанях між ЦОД в діапазоні до 100-150 км (і кілька більш), де виникають затримки (latency) до 5 мс (це пов'язано з тим, що RTT-час пакета в каналі потрібно помножити на два для FC-кадру, саме два пакети необхідно, щоб донести операцію запису). Але і 150 км - це зовсім немало.
До появи VMware vSphere 5 існували деякі варіанти конфігурацій для інфраструктури віртуалізації з використанням загальних томів обох майданчиків (з підтримкою vMotion), але розтягнуті HA-кластери не підтримувалися.
З виходом vSphere 5 з'явилася технологія vSphere Metro Storage Cluster (vMSC) , Підтримувана на сьогоднішній день тільки для вирішення EMC VPLEX, але підтримувана повністю згідно HCL в плані технологій HA і vMotion:
Зверніть увагу на компонент посередині - це віртуальна машина VPLEX Witness, яка представляє собою "свідка", який спостерігає за обома майданчиками (сам він розташований на третій площадці - тобто ні на одному з двох ЦОД, щоб його не торкнулася аварія на жодному з ЦОД ), який може відрізнити падіння линка по мережі SAN і LAN між ЦОД (екскаватор розрізав дроти) від падіння одного з ЦОД (наприклад, потрапляння ракети) за рахунок моніторингу майданчиків по IP-з'єднанню. Залежно від цих обставин персонал організації може зробити ті чи інші дії, або вони можуть бути виконані автоматично за певними правилами.
Тепер якщо у нас виходить з ладу основний сайт A, то механізм VMware HA перезавантажує його ВМ на сайті B, обслуговуючи їх введення-виведення вже з цього майданчика, де знаходиться вижила копія віртуального сховища. Те ж саме у нас відбувається і при масовому відмову хост-серверів ESXi на основному майданчику (наприклад, дематеріалізація блейд-кошики) - віртуальні машини перезапускати на хостах розтягнутого кластера сайту B.
Абсолютно аналогічна і ситуація з відмовами на стороні сайту B, де теж є активні навантаження - його машини передут на сайт A. Коли сайт відновиться (в обох випадках з відмовою і для A, і для B) - віртуальний тому буде синхронізований на обох майданчиках ( тобто Failback повністю підтримується). Всі інші можливі ситуації відмов розглянуті тут .
Якщо відмовить тільки мережу управління для хостів ESXi на одному майданчику - то розумний VMware HA залишить її віртуальні машини запущеними, оскільки є механізм для обміну хартбітамі через Datastore (див. тут ).
Що стосується VMware vMotion, DRS і Storage vMotion - вони також підтримуються при використанні рішення EMC VPLEX Metro. Це дозволяє переносити навантаження віртуальних машин (як обчислювальну, так і сховище - vmdk-диски) між ЦОД без простою сервісів. Це відкриває можливості не тільки для катастрофостійкості, але і для таких стратегій, як follow the sun і follow the moon (Але 100 км для них мало, спеціально для них зроблена технологія EMC VPLEX Geo - там вже 2000 км і 50 мс latency).
Найцікавіше, що скоро приїде цей самий VPLEX на обидві площадки (де вже є DWDM-канал і єдиний SAN) - тому ми всі будемо реально налаштовувати, що, безумовно, круто. Так що чекайте чогось про цю справу цікавого.
Таги: VMware, HA, Metro, EMC, Storage, vMotion, DRS, VPLEX
