Як ми перенесли дисковий простір сотень філій банку в одну СГД в Москві без втрати LAN-швидкостей на місцях

Дано: банк з дата-центром у Москві та безліччю філій.

У дата-центрі стоїть купа x86-машин і серйозна хайэндовая система зберігання даних (СЗД). У філіях реалізована мережі з центральним сервером або міні-кластером (+ резервним сервером і low-end сховищем), з дисковою кошиком. Бекап загальних даних робиться на стрічці і ввечері сейф) або ж на інший сервак поруч з першим. Критичні дані (фінансові транзакції, наприклад), асинхронно реплікуються в центр. На сервері працює Exchange, AD, антивірус, файловий сервер і так далі. Є ще дані, які не є критичними для банківської мережі (це не прямі транзакції), але все ще дуже важливі — наприклад, документи. Вони не реплікуються, але іноді бекапятся ночами, коли філія не працює. Через півгодини після закінчення робочого дня всі сесії гасяться, і починається велика копіювання.


Ось приблизно так це було влаштовано до початку робіт

Проблема, звичайно, в тому, що все це починає повільно збільшувати технологічний борг. Хорошим рішенням було б зробити VDI-доступ (це позбавило б від необхідності тримати величезну сервісну команду і сильно полегшило б адміністрування), але VDI вимагає широких каналів та малих затримок. А це в Росії не завжди виходить елементарно через відсутність магістральної оптики в ряді міст. З кожним місяцем збільшується кількість неприємних «передаварійних» інцидентів, постійно заважають обмеження заліза.

І ось банк вирішив зробити те, що, начебто, дорожче за впровадження, якщо вважати безпосередньо, але сильно спрощує обслуговування серверної інфраструктури у філіях і гарантує схоронність даних філії: консолідувати всі дані в одну центральну СГД. Тільки не просту, а ще з розумним локальним кешем.

Дослідження

Природно, ми звернулися до світового досвіду — все-таки такі завдання вирішувалися вже кілька разів для гірничодобувних компаній напевно. Першою знайшлася корпорація Alamos Gold, яка копає золото в Мексиці і розвідує родовища в Туреччині.

Дані (а їх досить багато, особливо сирих від геологорозвідки) потрібно передавати в головний офіс в Торонто. WAN-вузькі канали, повільні і часто залежать від погоди. У підсумку вони писали на флешки і болванки і відправляли дані фізичної поштою або фізичними кур'єрами. ІТ-підтримка була натуральним «сексом по телефону», тільки ще з поправкою на 2-3 мовних стрибка через перекладачів. З-за необхідності зберігати дані локально одне тільки підвищення швидкості WAN не вирішило б проблеми. Компанія Alamos змогла уникнути витрат на розгортання фізичних серверів на кожному руднику, використавши Riverbed SteelFusion — спеціалізований пристрій Riverbed SFED, яке поєднує можливості підвищення швидкості WAN, середу віртуалізації Virtual Services Platform (VSP) і рішення SteelFusion для периферійної віртуальної серверної інфраструктури (edge-VSI). VSP дав локальні обчислювальні ресурси. Без модернізації каналів вдалося після отримання майстер-зліпка тома нормально передавати дані туди-сюди. Окупність інвестицій — 8 місяців. З'явилася нормальна процедура аварійного відновлення.

Почали колупати дане рішення і знайшли у виробника заліза ще два випадки, майже в точності описують нашу ситуацію.

Корпорації Bill Barrett Corporation знадобилося оновити обладнання на віддалених майданчиках, вона спочатку розглядала традиційне рішення на половину стійки», яке коштувало дорого, але не вирішило б багатьох поточних проблем. Крім того, швидше за все, треба було б збільшити смугу пропускання каналу до цих майданчиків, що в два рази збільшувало витрати. Високі витрати — не єдиний недолік цього підходу. ІТ-кваліфікація персоналу на віддалених майданчиках була обмежена, а передбачуване рішення вимагало, щоб хтось керував серверами, комутаторами і обладнанням резервного копіювання. Поставили теж Riverbed SteelFusion, в результаті кейс вийшов втричі дешевше традиційного рішення, а місця в стійках — істотно менше.

Юридична фірма Paul Hastings LLP розросталася, відкриваючи офіси в Азії, Європі та США, збільшувалася і кількість її центрів обробки даних (чотири центральних Цод і безліч невеликих Цодів на 19 офісів). Хоча така архітектура і забезпечувала працездатність віддалених офісів, але для кожного ЦОДа був потрібен менеджер і 1-2 аналітика, а також фізичні хост-сервери і стрічкові системи резервного копіювання. Це вимагало великих витрат, а в деяких регіонах захист даних була не такою надійною, як фірмі хотілося б. Вирішили так само, тільки другим мотивом була безпека.

Відповідно, прорахували це і ще пару варіантів у традиційних архітектурах і показали замовнику. Замовник довго думав, вважав, поставив купу питань і вибрав цей варіант з умовою тестового розгортання одного «філії» (до закупівлі заліза основного проекту) на тестових ж базах.

Ось що ми зробили

Ми не маємо можливості змінювати канали, але можемо ставити залізо і на стороні ЦОДа, і на стороні філії. СГД в дата-центрі нарізана на безліч томів, та з 2-4 з них працює кожен філіал (зв'язок инъективная: з одним і тим же томом не може працювати кілька філій). Дискові полиці і трохи серваков на місцях викидаємо, вони в ролі СГД та контролерів реплікації вже не потрібні. У дата-центрі ми ставимо прості оптимізатори трафіку Riverbed Steelhead CX + віртуальні пристрої SteelFusion Core, на місцях встановлюється пара Riverbed SFED (SteelFusion Edge).





Раніше сервери працювали з даними, розміщеними локально (на локальних дисках або на low-end СГД). Тепер сервери працюють з даними центрального СГД через локальну проекцію LUN-ів, забезпечувану SteelFusion. При цьому сервери «думають», що працюють з локальними томами в локальній мережі філії.

Основна залізка філії називається Riverbed SFED (SteelFusion Edge), вона складається з трьох компонент. Це SteelHead (оптимізація + стиснення трафіку), SteelFusion Edge (елемент системи централізації даних) і VSP (віртуалізація вбудованим гіпервізором ESXi).

Що вийшло

  • Адресація для філії — єдина LAN з центральної СГД (точніше, парою її томів). Сервера звертаються до центральної СГД як до инстансу всередині LAN.
  • При першому запиті блоки даних починають транслюватися з центру до філії (повільно, але тільки один раз). Забігаючи трохи вперед — ми використовуємо режим Pin the LUN, коли кеш (blockstore) дорівнює розміру LUN, тобто відразу знімаємо повний зліпок даних з центральної СГД на першому запуску.
  • При будь-якій зміні даних на нашій стороні вони встають в чергу на синхронізацію і відразу ж стають доступними «як ніби в центрі», але з кешу SteelFusion Edge, розташованого локально.
  • При трансфері даних в будь-яку з сторін використовується ефективне стиснення, дедупликация і оверрайды протоколів для їх оптимізації (громіздкі і «балакучі» протоколи транслюються пристроями оптимізовані для вузьких каналів з великою затримкою).
  • У загальному випадку всі дані завжди зберігаються у системі зберігання даних в центральному дата-центрі.
  • «На десерт» з'явився крутий префетчинг на рівні блоків. Читаючи зміст блоків і застосовуючи знання про файлових системах, SteelFusion здатний визначити, що OS фактично робить (наприклад, завантажується, запускає додаток, відкриває документ). Потім вона може визначити, які блоки даних знадобляться для читання, і завантажує їх, перш ніж ОС їх запросить. Що набагато швидше, ніж робити все послідовно.




На практичному рівні софт заробив майже без затримок, реплікація ночами забута як страшний сон. Ще одна особливість — у центрі реально всі дані філії. Тобто якщо раніше на локальних дисках могли бути традиційно «файлопомоечные» скани документів, презентації, різні некритичні документи і все те, що дорого звичайним користувачам, — тепер воно теж лежить в центрі і також легко відновлюється при збоях. Але про це і підвищення відмовостійкості трохи нижче. І природно, одну СГД обслуговувати куди простіше, ніж десяток. Більше ніякого «сексу по телефону» з «програмістом» з далекої невеликого містечка.



Монтуються вони ось так:



Що вийшло:

  • Так звані квазисинхронные реплікації (це коли для філії вони виглядають як синхронні, а для центру — як швидкі асинхронні).
  • З'явилися швидкі і зручні точки відновлення до хвилин, а не «мінімум на добу назад».
  • Раніше при пожежі у філії була загублена локальна файлова кулі і пошта співробітників міста. Тепер все це теж синхронізується і при аварії не загубиться.
  • Нова коробка спростила всі процедури branch recovery — новий офіс розгортається на новому залізі за лічені хвилини (так само розгортається нове місто з готових образів).
  • Довелося прибрати з інфраструктури серваки на місцях, плюс викинути малі стрічкові накопичувачі для бекапа теж на місцях. Замість цього було докуплено залізо Riverbed, дозаполнена дисками центральна СГД і куплена нова велика стрічкова бібліотека для бекапа, встановлена в іншому московському дата-центрі.
  • Покращилася безпека даних завдяки єдиним і легко контрольованим правил доступу і більш стійкого шифрування каналу.
  • При катастрофі філії, що супроводжується знищенням інфраструктури, з'явилася проста можливість запустити віртуальні сервера в самому Цоді. В результаті чого стрімко зменшуються RTO і RPO.


Що буває при короткому обриві зв'язку?

У поточній інфраструктурі — нічого особливого. Дані продовжують записуватися в кеш SFED, при відновленні каналу синхронізуються. Користувачам при запиті «в центр» віддається локальний кеш. Варто додати, що проблема «шизофренії» не виникає, оскільки доступ до LUN-є тільки через SFED конкретного філії, тобто з боку Цод у наш тому ніхто не пише.

Що буває при обриві зв'язку більше 4 годин?

При тривалому обриві зв'язку може наступити такий момент, коли локальний кеш SFED заповниться, і файлова система буде сигналізувати про те, що місця для запису недостатньо. Потрібні дані не зможуть бути записані, про що система попередить користувача або сервер.

Ми кілька разів тестували таку схему аварійного філії в Москві. Розрахунок часу такий:
  1. Час доставки ЗІП.
  2. Час початкової конфігурації SFED (< 30 хвилин).
  3. Час завантаження ОС віртуальних серверів через канал зв'язку при порожньому кеші.
Час завантаження Windows на каналі зв'язку із затримками в 100 мілісекунд становить менше 10 хвилин. Фішка в тому, що для завантаження ОС не потрібно чекати, поки всі дані з диска C будуть передані в локальний кеш. Завантаження ОС, природно, прискорюють інтелектуальний поблочный префетчинг, про який говорилося вище, і просунута оптимізація Riverbed.



Навантаження на СГД

Природно, падає навантаження на центральну СГД, адже більша частина робіт лягає на пристрої у філіях. Ось картина від виробника на тестах оптимізації роботи СГД, адже до неї тепер набагато менше звернень:



Пояснення про режими квазисинхронной реплікації

До цього я говорив про Pin the LUN, коли кеш дорівнює LUNу. Оскільки кеш на пристроях у філіях не апгрейдиться (потрібно купувати нову залізяку або ставити другу поруч, і до того моменту, коли це буде потрібно — через 4-5 років, вони вже будуть нового покоління, швидше за все, потрібно врахувати і вимога різкого підвищення кількості даних у філії. Планове розраховано і укладено на багато років вперед, а ось непланове буде вирішуватися перемикання у режим Working Set.



Це коли blockstore (локальний кеш-словник) менше даних філії. Зазвичай частка кеша в порівнянні з загальною кількістю даних — 15-25%. Тут немає можливості працювати повністю автономно, використовуючи кеш як копію центрального LUNа: в цей момент в режимі відмови каналу зв'язку запис йде, але ставиться в буфер. Канал відновиться — віддамо запис в центрі. При запиті блоку, якого немає в локальному сховищі, генерується звичайна помилка з'єднання. Якщо блок є — дані віддаються. Я припускаю, що через ті 5 років, коли обсяг даних перевищить місткість кеша філій, адміни не будуть докуповувати залізо, а просто централізують пошту і переведуть файлшару в режим Working Set, критичні дані залишать в режимі Pin the LUN.

І ще одне. Доукомплектація другим SFED створює відмовостійкий кластер, що також може бути важливим у перспективі.

Тести і досвідчена експлуатація

Ми робили таке досить незвичайне об'єднання і віртуалізацію СГД вперше — від інших проект відрізняється саме налаштуванням локальних blockstore, ув'язаних в ПАК з оптимізаторами трафіку і серверами віртуалізації. Я кілька разів розвалював і збирав кластери з пристроїв, щоб подивитися можливі проблеми в процесі. Пару раз на істотному перекофигурировании зловив повний прогрів кешу на філіалі, але знайшов спосіб обходити це (коли не потрібно). З підводних каменів — досить нетривіально робиться повне обнулення blockstore на одному конкретному пристрої, цього краще навчитися на тестах до роботи з бойовими даними. Плюс на тих же тестах зловили один екзотичний креш ядра на центральній машині, детально описали ситуацію, відправили виробнику, вони надіслали патч.

З часу відновлення — чим ширший канал, тим швидше дані відновляться у філії.

Важливо, що ядро не дає можливості в пріоритеті віддавати дані конкретним SFED, тобто операції СГД та канали використовуються рівномірно — дати «зелене» на швидкий трансфер даних впав філія засобами цього ПАК не вийде. Тому ще одна рекомендація — залишати невеликий запас потужності СГД для таких випадків. У нашому випадку потужності СГД вистачає за очі. Тим не менш, можна конфігураціями QoS на тих же SteelHead або інших мережних пристроях виділити смугу пропускання під кожну філію. І з іншого боку, обмежити трафік синхронізації SteelFusion, щоб не страждав трафік централізованих бізнес-додатків.

Другий за важливістю — стійкість до обривів. Як я розумію, голос за проект додали і їх безпечники, яким ідея тримати всі дані в центрі припала дуже навіть до душі. Адміни ради, що більше не літають на місця, але, звичайно, деяка частина локальних «эникеев» постраждала, тому що стрічку і серваки вже не треба було обслуговувати.

Сама по собі ця архітектура на залозі Riverbed дозволяє ще робити купу всього, зокрема, нишпорити принтери по містах, робити не зовсім звичайні проксі і файрволли, використовувати серверні потужності інших міст для великих прорахунків і т. п. Але нам в проекті це не потрібно (принаймні поки що), тому залишається тільки радіти і дивуватися, скільки ще фіч можна наковырять.

Залізо

SteelFusion Edge: конвергентне пристрій, який об'єднує сервера, сховища, мережа і віртуалізацію для роботи локальних додатків філії. Ніяка інша інфраструктура у філії більше не потрібно.



SteelFusion Core: контролер доставки СГД розміщується в Цоді і взаємодіє з СГД. SteelhFusion Core проектує централізовані дані філії, усуваючи бекапи у філіях, і забезпечує швидке розгортання нових філій і відновлення після катастроф.



Посилання

Власне, можливо, вам буде ще цікаво дізнатися:


Джерело: Хабрахабр

0 коментарів

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