Як ми робили централізоване зберігання даних для роздрібної мережі і оптимізували його по кроках

Після того як ми розповіли про перенесення сховищ сотень відділень великого банку до центрального ЦОД, використовуючи рішення Riverbed, ми вирішили трохи заглибитися в технічно «стораджовую» складову продуктів, а заодно і подумати над варіантом консолідації даних, наприклад, у великого ритейлера, перевірити ефективність систем SteelFusion Core і Edge, а також оцінити інженерні зусилля і вигоду замовника.

По нашому досвіду типовий регіональний філіал ритейлера будується на парі мережевих комутаторів, парі серверів, стрічкової бібліотеки і прибиральниці, яка змінює касети. Іноді бібліотеці віддають перевагу зовнішній диск. Касети можуть просто зберігати, а можуть вивозити з певною періодичністю. Те ж саме і з зовнішнім диском. Ширина WAN-каналу обмежена парою Мбіт/с і рідко коли досягає високих значень.

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



Одну з лабораторій ми взяли за уявний центральний офіс (ЦОД), де розгорнули vCenter і зібрали простенький HA-кластер…

В лабораторії, що виконує роль філії, ми встановили єдину залізяку Edge. Вузький канал імітували емулятором WANem, отримуючи характеристики пропускної спроможності 2048-3072 кбіт/с при затримці 20 мс. Втрати пакетів у тестуванні моделювати не стали.

Блоки даних між майданчиками здійснюють руху після стиснення і дедуплікаціі потоку iSCSI-трафіку оптимізатором. Спрощена схема для кращого розуміння — нижче.



Для проекції дискового простору філія використовується шлюз SteelFusion Core (SFC). Ми встановили його в якості віртуальної машини в Цоді. Для оптимізації трафіку в Цоді ми також використовували віртуальний SteelHead VCX, на якому налаштували відповідне правило перехоплення трафіку і перенаправлення його через оптимізатор.

Філіальна залізка влаштована оригінально. Сервер Edge (в нашому випадку 3100) розділений на дві ноди:
• RiOS-нода, що відповідає за роботу сервісів Riverbed (оптимізація трафіку, управління blockstore, гіпервізором тощо).
• Нода з гіпервізором ESXi, преднастроенная в мережевій частині.



Диски в сервері — це кеш blockstore Edge. Управляється він тільки нодою RiOS, яка, в свою чергу, виділяє рівне місяць простір в кеші для ESXi. При цьому доступ ESXi-ноди до blockstore (фактично до дисків в тій же залізній коробці) здійснюється за протоколом iSCSI на швидкості 1 Гбіт/с через внутрішній інтерконнект.

У нас в конфігурації стояли 4 диска 2ТБ SATA 7.2 ДО RAID10 і 4 диска SSD 240 GB також в RAID10. Hot-spare дисків немає, але зате можна з-під CLI примусово повернути несправний диск в групу. Це корисно, коли необхідно відновити дані при відмові відразу декількох дисків. Всього під blockstore доступно трохи більше 3 ТБ.

Настроювання маршрутизації та оптимізації Rdisk-трафіку складно помилитися, якщо зробити все правильно. Є чіткі схеми, яким необхідно слідувати. В іншому випадку в якості бонусу до шаленої системі даються постійні розриви прямої зв'язки Edge — Core, нестабільна робота RiOS-з'єднань і поганий настрій, що ми спочатку і отримали, банально загорнувши трафік з Edge на неправильний інтерфейс оптимізатора VCX.

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





Далі ми вирішили капітально навантажити Edge віртуальною машиною з Exchange і через LoadGen імітували активну роботу близько 500 осіб. При цьому операційна система ВМ була встановлена на vmdk-диск, а сам Exchange — на RDM об'ємом 150 Гб.

Ясна річ, що для таких навантажень SFED не призначений, але чим чорт не жартує… Додатково ми вирішили погратися з розривом зв'язку Core — Edge, щоб переконатися у коректному поведінці і стабільності системи.

Що цікавого помітили

При працюючій оптимізації та скорочення обсягу переданих даних до 90%, кеш blockstore заповнювався настільки стрімко, що не тільки не встигав правильно, але і добряче вішав систему. Коли SFED з завидним апетитом проковтнув 3 ТБ місця в blockstore, хост почав отримувати помилки запису.



Як виявилося, наша конфігурація не була правильною з точки зору демонстрації роботи оптимізації трафіку. Причини наступні:
  • RDM-диск, який кешується в blockstore, але при реплікації потік не дедуплицируется. Оптимізація працює тільки при використанні VMFS-сховищ і дисків VMDK всередині них. Звідси вкрай повільна реплікація тома з Exchange.
  • До роботи Exchange у нашій віртуальній машині активно залучався файл підкачки, який лежав на системному диску ОС всередині датастора. Відповідно під оптимізацію потрапляв саме він і його динамічні зміни. Звідси великий відсоток скорочення обсягу даних на графіках і поспішне радість.
  • Непропорційне заповнення кеша пов'язано з типом використовуваного під систему диска Thick, Lazy Zeroed.
І з цього моменту детальніше.

Різні типи форматування VMDK-дисків по-різному кешируются в blockstore.

Приклад: VMDK-диск об'ємом 100 Гб з використаними 20 Гб






Vmdk type
WAN traffic usage
Space utilized on array thick luns
Space utilized on array thin luns
Vmdk Fragmentation
Thin
20 ГБ
20 ГБ
20 ГБ
High
Thick eager Zero
100 GB + 20 GB = 120 ГБ
100 ГБ
100 ГБ
None (flat)
Thick lazy zero (default)
20 GB + 20 GB = 40 ГБ
100 ГБ
20 ГБ
None (flat)



Так, найбільш ефективно утилізується blockstore при використанні тонких томів. Двократне збільшення кількості кешированных і реплицируемой даних спостерігається при використанні Lazy Zeroed дисків за рахунок занулення блоків VMFS Datastore при першій запису. Найбільш «ненажерливим» є метод Eager Zeroed, т. к. кешируются і нульові блоки на весь обсяг, і блоки записаних даних. Подальше тестування кешування дисків різних типів призвело до очікуваних результатів — кеш заповнювався рівно настільки, наскільки був повинен.

Наступним нашим кроком стала перевірка ефективності використання системи при розгортанні нової інфраструктури. Ми обнулили кеш blockstore для чистоти експерименту, підготували в Цоді VMFS-сховище з віртуальною машиною і приступили.







ОС віртуальної машини
Ubuntu
Ubuntu
Сховище віртуальної машини
ЦОД через Core
ЦОД
Об'єм диску ВМ
16 ГБ
16 ГБ
Обсяг boot-даних
~ 370 МБ
Ширина WAN-каналу
100 Мбіт/с







Робота з широким каналом не настільки ефективна при першому завантаженні готової віртуальної машини. Але сама робота ВМ відчутно швидше, т. к. корисних блоків передається все менше, а Read Hit в кеші blockstore стає все більше.



Переваги оптимізації очевидні там, де каналу практично немає.



Коли ми встановлювали ВМ на Edge, ми, звичайно ж, розмістили завантажувальний образ на спроецированном датасторе, тим самим не даючи йому откешироваться в blockstore заздалегідь.

Процес установки ВМ і результати оптимізації переданих даних:



Статистика blockstore за показниками Read Hit і Read Miss:



Статистика оптимізації TCP-з'єднань:



Завантаженість WAN і LAN-каналів:



Тут ми бачимо, наскільки за фактом утилізований WAN-канал і яку фактичну швидкість передачі даних забезпечує оптимізація трафіку.

Через годину наша свежеустановленная ВМ повністю поїхала в ЦОД. На графіку бачимо, як знижується обсяг реплицируемой даних.



Залишався головне питання: як все це справа бекапить, і бажано з більшою часткою автоматизації? Відповідь: використовувати вбудований в Edge-Core функціонал снапшотов.

Снапшоти можуть бути двох типів — Application Consistent (додаток записує буфери даних на диск, після чого робиться знімок томи) та Crash Consistent (знімок тома без записаних даних з буферів, рівносильний запуску програми після аварійного завершення).
Application Consistent снепшоты працюють з віртуальними машинами через VMWare Tools у разі використання VMDK, а також через VSS у випадку з NTFS.

Ми тестували даний функціонал у зв'язці ESXi та СГД IBM Storwize V7000.

Як це працює:



Механізм:
  1. За розкладом Edge посилає команду ESXi-хосту на створення Application Consistent снепшота.
  2. Отримуючи команду, ESXi-хост посилає через VMware Tools команду гостьовим ВМ записати дані буферів.
  3. Після завершення процесу flushing буферів Edge поміщає спеціальний маркер в потік даних, реплицируемой в ЦОД (commit string).
  4. Edge з'єднується з колишнім ESXi-хостом і видаляє раніше знятий снепшот.
  5. Маркер в WAN-каналі досягає Core, всі дані до маркера записуються на лун на дисковому масиві.
  6. Після запису даних до маркера Core звертається до дискового масиву з командою на ініціалізацію снепшота місяць.
  7. Після того як дисковий масив створив снепшот, Core з'єднується з Proxy-Backup-сервером також на ESXi, дерегистрирует минулі ВМ і відключає datastore.
  8. Потім Core знову з'єднується з дисковим масивом, створює клон снепшота і презентує його з масиву проксі-сервера.
  9. Після цього Core інструктує проксі-сервер змонтувати снепшот і імпортувати віртуальні машини.
І все. Віртуальні машини доступні для бекапа будь-яким сумісним з vSphere софтом. Ми взяли Internet і успішно зробили резервну копію тестової машини.



В результаті ми отримуємо: використовувати окремі сервери і локальні диски в серверах — це дешево і швидко, але виникають питання з довгостроковим зберіганням даних та безліччю накладних витрат. При цьому бекап, звичайно, можна робити як на стрічку у філії, так і використовуючи різний софт, приміром, CommVault зі своїми механізмами дедуплікаціі і стиснення трафіку.

У разі консолідації даних в ЦОД, використовуючи SteelFusion, необхідно спочатку розташовувати відповідним кількістю ресурсів для зберігання регіональних даних та їх бекапу. Додаткова економія на бекапе можлива, якщо ліцензувати Proxy Backup сервери в ЦОД за кількістю сокетів в залежності від планованого навантаження філій.

Якщо розглядати класичну компоновку філії та її приблизну вартість по ключових позиціях, то отримаємо таку картину:














Класична компоновка (філія)
Приблизна вартість $
2 x-Сервер (1 CPU, 32GB RAM, 5×600GB HDD)
20 000
Стрічкова бібліотека (1 драйв)
10 000
Розширена підтримка (24/7/6h), 1 
7 000
VMware vSphere Std.: ліцензія на 2 сокета
4 000
Підписка на 2 сокета, 1 
1 500
Резервне копіювання: ліцензія на 2 сокета
2 000
Підтримка, 1 
5 000
CAPEX(перший рік)
49 500
OPEX(наступні 4 року)
54 000
TCO (5 років)
103 500
TCO на 30 філій (5 років)
3 105 000



Використовуючи конфігурації SteelFusion у філії, отримуємо:













Компонування SteelFusion (філія)
Приблизна вартість $
Обладнання:
2 х SteelFusion Edge 2100
31 000
Підтримка обладнання та :
SteelFusion Edge Appliance 2100 Gold Support, 1год
9 500
Ліцензії НА:
VSP, BlockStream, WAN Opt (1500 Connections, 20 Mbps)
7 800
CAPEX (перший рік)
48 300
OPEX (наступні 4 року)
38 000
TCO (5 років)
86 300
TCO (30 філій, 5 років)
2 589 000



В ЦОД ставимо дві віртуальні машини SteeFusion Core і два залізних Steelhead.














Компонування SteelFusion (ЦОД)
Приблизна вартість $
Обладнання:
2 х SteelFusion Core VGC-1500
46 800
2 х SteelHead CX 770
30 400
Підтримка обладнання, 1 рік:
SteelFusion Core Virtual Appliance 1500 Gold Support, 1год
9 400
SteelHead CX Appliance 770 Gold Support, 1год
5 400
Ліцензії НА:
License SteelHead CX 770-H, 30Mbps, 2500 conn
21 600
CAPEX (перший рік)
113 600
OPEX (наступні 4 року)
59 200,00
TCO (ЦОД, 5 років)
172 800



Розглядаючи TCO за 5 років, отримуємо економію як мінімум $300 000 при використанні рішення SteelFusion. І це без додаткових накладних витрат в класичному варіанті. А враховуючи можливості стиснення не тільки блочного потоку реплікації, але і різних прикладних протоколів, можна додатково скоротити витрати на канали зв'язку.

Посилання

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

0 коментарів

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