Оповідь про віртуалізації-кластеризації та СГД Fujitsu


Справа була так.
Одна маленька організація державних масштабів вирішила оновити у володінні своєму місцевому серверне обладнання. І звернулися її мужі до наших доблесних менеджерам, мовляв, хочемо ми серверів з дисками для сервісів наших важливих. І довідалися вони від менеджерів про віртуалізації заморської, відмовостійкої та з кластеризацией.
Власне, довго казка мовиться, та швидко справа робиться.
Так і з'явилася в організації тієї зв'язка з двох серверів Fujitsu PRIMERGY RX 200 S8 і системи зберігання даних ETERNUS DX 100 S3. І ніхто на той момент не думав, що дуже скоро ресурсів серверів тих не бракуватиме. А навпаки, вважали і були впевнені, що вистачить надовго. Але швидко віртуальні машини стали плодитися і ненажерливі вони були так ситі. І тоді було розширено дисковий простір, а до двох RX 200 підселився брат їх юний Fujitsu PRIMERGY RX2530 M1.
Про підселення нового сервера в кластер, а також про додавання в контролерні блоки нових карт розширення з додатковими FC-інтерфейсами ми і розповімо. А вірніше, про простоті, безпечності та зручності всіх цих та інших інженерних маніпуляцій, які можливі (в нашому випадку) з віртуалізацією VMware і обладнанням Fujitsu. Ті, хто вже має СГД і ту або іншу реалізацію віртуалізації серверів (або просто в темі) не здивуються й, напевно, не почерпнуть нічого нового з цього тексту. Але є ще багато організацій, де які-небудь дії з обладнанням, його запуском і зупинкою викликають жах і змушують ретельно планувати і мінімізувати майбутній downtime.

Про систему зберігання даних
Як відомо, для того щоб додати або прибрати будь-який компонент (не підтримує «гарячу» заміну) вже працюючому пристрої, надає сервіси і постійно обменивающимся даними, це пристрій потрібно вимкнути. У випадку з сервером така зупинка неминуча, у випадку з сучасними СГД, що мають два контролера, все робиться без зупинок і пауз. Дійсно, крім відмовостійкості допомогою многопутевого вводу-виводу (MultiPathing – кожен з вузлів (серверів) має по кілька каналів передачі даних від своїх I/O портів до портів кожного з контролерів СГД), сучасні системи зберігання даних (зокрема, мова йде про Fujitsu ETERNUS DX 100 S3) вміють розподіляти/распараллеливать передачу даних по цих каналах, зменшуючи навантаження на канал і збільшуючи пропускну здатність. Час простою при відмові одного з каналів зведено до нуля (active / active режим) або мінімізовані при автоматичному перемиканні з активного (але «втраченого») каналу на пасивний – «очікування» (active / passive режим). Власне, ці можливості, а також особливості операційної системи дозволяють нам вносити зміни в контролерні блоки (або замінювати їх повністю) без простоїв і перезавантажень.
З DX 100 S3 це легко і просто виконується таким чином, що відображає всю безпеку і продуманість маніпуляцій:
  1. Увійшовши в GUI під обліковим записом сервісного інженера (f.ce), всю систему переводимо в режим обслуговування

  2. Далі, вибравши потрібний нам контроллерный модуль, переводимо його в режим обслуговування
Система перед введенням шуканого блоку в maintenance mod виконає ряд тестів безпеки і реалізує запит тільки якщо другий контролер і залежні компоненти працюють штатно і цілісності даних нічого не загрожує. Всі логічні диски, для яких відключений контролер був «власником», перейдуть на обслуговування другого контролера практично миттєво і легко після синхронізації кеша і зміни шляхів передачі даних.
  1. В графічному інтерфейсі стане видно, що контролер більше не доступний і може бути витягнутий. По закінченні маніпуляцій, так само в онлайн режимі повертаємо його на місце, система автоматично, без перезавантажень самих контроллерных блоків, розпізнає і поверне колишню схему роботи. З'явилися нові пристрої (у нас це FC-адаптери) потрібно задіяти, додавши в систему. Ось і все, воістину у ETERNUS DX операційна система «реального часу».
лінійки IBM (Lenovo) Storwize, наприклад, дані маніпуляції теж проходять онлайн, але самі контролери виконують цикл з кількох почергових перезавантажень після зазначення того, що це зовсім не помилка і це ми додали той чи інший компонент. І перезавантаження можуть тривати, за показаннями системи, до 30 (!!!) хвилин кожна.

Хочеться додати ще кілька слів про реалізованому тут алгоритмі безпеки, можна сказати, захист від необдуманих дій. А суть його проста і витончена: не можна що-небудь видалити ненавмисним натисканням не туди, куди треба. Наприклад, ми не можемо видалити RAID-масив або логічний диск поки не розберемо весь ланцюжок взаємозв'язків з самого «кінця», а саме – спочатку потрібно вилучити LUN-групи з налаштувань зв'язку з хостом (Host Affinity), далі самі логічні диски прибрати з LUN-груп, видалити логічні диски і тільки потім зруйнувати RAID. Погодьтеся, зробити таке випадково і ненавмисно практично неможливо.


Вкладки "Delete" LUN Group і RAID Group не активні до розриву "зв'язків"
Варто обмовитися, що з командного рядка (SSH) при необхідності примусове видалення будь-яких елементів доступно відразу.
Про серверах і віртуалізації
Як вже згадувалося раніше, серверна частина кластера спочатку складалася з 2-х серверів Fujitsu PRIMERGY RX200 S8, до яких в подальшому додали аналогічне по класу і продуктивності пристрій Fujitsu PRIMERGY RX 2530 M1. По суті, архітектурно пристрої дуже схожі, але нова лінійка процесорів Intel (як наслідок і нові функції, інструкції, протоколи) RX 2530 M1 обіцяла нам проблеми на рівні кластера VMware, а саме, проблеми з міграцією машин між хостами. Що й проявилося після впровадження: деякі з вже наявних машин при міграції видавали помилку, пов'язану саме з відзнакою CPU цільового сервера.
Звичайно ж, VMware передбачила рішення для подібного роду проблем, її функція EVC (Enhanced vMotion Compatibility) призначена для «маскування» відмінностей у процесорах різних поколінь. На жаль, спочатку кластер піднімався на п'ятій версії віртуальної сфери VMware (VMware vSphere 5.5), яка тоді ще «поняття не мала про нових процесорах Intel. Проте суть в тому, що для нашої ситуації ця біда – зовсім не біда. Маючи відмовостійкий кластер, оновлення до версії VMware vSphere 6.0 (EVC якої має можливість працювати з усіма версіями процесорів) займає всього кілька годин. При правильному використанні і плануванні кластера будь з наявних в ньому серверів можна вільно обслуговувати, розподіливши його машини на хостах, використовуючи «живу» міграцію.

Міграція машини здійснювалася зі зміною не тільки хоста, але і сховища даних, так як виконувалася реорганізація дискового простору СГД. Даний процес протікає шляхом повного клонування машини, оригінал якої після синхронізації автоматично видаляється. Одночасна міграція (сервер і диск) можлива тільки при вимкненій віртуальній машині.

VMware vSphere 5.5 підтримка процесорів закінчується поколінням "Sandy Bridge"

VMware vSphere 6.0 ми можемо спостерігати "Ivy Bridge" і "Haswell"
Підбиваючи підсумок цієї невеликої історії про кластерної віртуалізації, хочеться процитувати рядок з пісні – «Літати з тобою мені було важко, але без тебе я не можу дихати!». Бо зважитися на це важко, та й дорого. Але зате потім страшно уявити, як раніше без усього цього обходилися, згадуючи витрачені вихідні, обіди і ночі, нерви, переживання і надію встигнути завершити задумане до кінця перерви або початку робочого дня.
Підготовлено за матеріалами Третьякова В'ячеслава, інженера компанії «Парадигма». Повну версію статті дивіться тут.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.