«КПД» стандартного WAN - всього близько 10%
Якщо заглянути в практично будь-який канал зв'язку між філією компанії і дата-центром, то можна побачити досить неоптимальну картину:
- По-перше, передається дуже багато (до 60-70% каналу) надлишкової інформації. яка так чи інакше вже було запитано про.
- По-друге, канал завантажений «балакучими» додатками. розрахованими на роботу в локальній мережі, - вони обмінюються короткими повідомленнями, що негативно позначається на їх продуктивності в каналі зв'язку.
- По-третє, сам протокол TCP спочатку створювався для локальних мереж і відмінно підходить для малих затримок RTT і при відсутності втрат пакетів в мережі. У реальних каналах при втратах пакетів швидкість сильно деградує і повільно відновлюється за рахунок великих RTT.
Я працюю керівником інженерної команди департаменту телекомунікацій КРОК і регулярно оптимізує канали зв'язку дата-центрів як наших, так і енергетичних компаній, банків та інших організацій. Нижче розповім основи і приведу найбільш цікаве, на мій погляд, рішення.
Стиснення і дедуплікація
Перша проблема вже описана: в каналі передається дуже багато надлишкових дублюються даних. Найяскравіший приклад - це Citrix-ферма, в якій працюють філії якогось банку: в окремо взятому офісі одні й ті ж дані можуть запитувати 20-30 різних машин. Відповідно, канал можна було б спокійно розвантажити на 60-70% за рахунок дедуплікаціі.
На самому Citrix, звичайно, можна включити стиск даних, але ефективність (стиснення) в рази нижче, ніж на спеціалізованих оптимізаторів трафіку. Головним чином за рахунок того, що оптимізатори не тільки стискають дані, але і дедупліціруют. Через оптимізатор проходить трафік всього філії. І чим більше користувачів у філії, тим більше повторюваних запитів користувачів і тим більше ефект від дедуплікаціі. Для одного користувача стандартне стиснення, наприклад Limpel-Ziv, може бути навіть вище, ніж дедуплікація, але при наявності більшої кількості пристроїв на перше місце вийде саме дедуплікація.
Як правило, оптимізатори - це ПАК, але можна впровадити і в вигляді віртуальних машин. Для оптимізації трафіку на каналі зв'язку оптимізатори повинні бути встановлені на обох майданчиках. Оптимізатори ставляться до VPN-шлюзів, оскільки дедуплікація шифрованого трафіку - справа марна.
Алгоритм роботи дедуплікаціі наступний:
Залишається додати, що словник постійно оновлюється і, завдяки спеціальним алгоритмом, в словнику залишаються найбільш затребувані блоки даних.
Ще одна проблема полягає в тому, що швидкість TCP обмежена розміром вікна (TCP Windows Size). Розмір вікна - обсяг даних, що передаються відправником до отримання підтвердження від одержувача. При цьому для передачі ущільненого трафіку потрібно менше раз передавати TCP Windows Size, що веде до збільшення швидкості передачі.
Отже, ще раз, це працює так:
- Пристрій А дедупліцірует трафік.
- Пристрій Б збирає «повну картину» зі свого локального сховища.
- Обидва цих пристрої працюють симетрично.
- Обидва цих пристрої ніяк не впливають на інфраструктуру і конфігурація всього того, що лежить за ними, тобто просто включаються в розрив каналу, наприклад, на виході з дата-центру і вході в регіональний офіс компанії.
- Пристрої ніяк не обмежують зв'язок з вузлами, де таких пристроїв немає.
Дедуплікація для шифрованих каналів
Шифрований канал явно гірше підходить для стиснення і дедуплікаціі, тобто практичної користі від роботи з уже шифрованих трафіком майже немає. Тому оптимізатори включаються в розрив до пристрою шифрування: ЦОД віддає дані оптимізатора, оптимізатор віддає на шифровку (наприклад, в захищений VPN-канал), на тій стороні трафік розшифровується і віддається оптимізатора на місці, а той уже віддає їх в мережу. Це штатна функція «коробочок-оптимізаторів», і все це відбувається без зниження ризиків компрометації трафіку.
Дедуплікація для мобільних співробітників
В останні роки досить часто з ЦОДамі безпосередньо працюють люди з ноутбуками і планшетами, яким теж потрібно досить багато даних (ті ж образи віртуальних машин або вибірки з БД). Для них використовуються не «коробочки-оптимізатори», а спеціальний софт, який просто витрачає частину ресурсів процесора і частина жорсткого диска для тих же цілей. За фактом ми міняємо деяке зниження продуктивності ноутбука і місце в кеші на жорсткому диску на більш швидкий канал. Користувачі зазвичай не помічають нічого, крім прискорення роботи мережевих сервісів.
Хто робить ці оптимізатори?
З точки зору комерційного директора замовника, це кілька коробок, які після простого включення в мережу прискорюють повільні канали в 2-3 рази і знижують завантаження каналів від 2 разів. За це їх люблять майже всі!
підключення оптимізатора
Найпростіший і надійний спосіб - «в розрив» між граничним маршрутизатором і комутатором ЛВС. Якщо оптимізатор виходить з ладу, він замикає контакти інтерфейсів LAN і WAN - і трафік просто проходить через нього, як через звичайний крос-кабель. Відповідно, бачачи неоптимізований трафік, оптимізатор на тій стороні також просто пропускає його через себе без обробки.
- Зв'язок філії з оптимізатором і Цода з оптимізатором - трафік оптимізується.
- Зв'язок філії без оптимізатора і Цода з оптимізатором - оптимізатор Цода просто прозоро пропускає трафік без змін.
- Зв'язок філії з оптимізатором і Цода з оптимізатором при виході будь-якого з оптимізаторів з ладу - трафік просто не стискується і ходить «як є».
Природно, в ЦОДах оптимізатори кластеризуються для відмовостійкості або нарощування потужності плюс забезпечуються балансувальник Interceptor. Але про це трохи нижче, коли дійдемо до конкретного обладнання.
прискорення TCP
Швидкість роботи TCP обмежена розміром вікна. Вікно - це кількість інформації, яке сервер може відправити клієнту до отримання підтвердження про отримання.
Стандартну поведінку TCP виглядає так:
- повільний розгін з'єднань, розмір TCP-вікна збільшується;
- при втратах пакетів - різке падіння в швидкості (зменшення вікна в 2 рази);
- і знову повільне її збільшення (збільшення вікна);
- знову втрати пакетів і просідання смуги і так далі.
Помаранчева «пила» на графіку - стандартна поведінка TCP
На каналах зв'язку з великою пропускною здатністю, але наявністю будь-якого рівня втрат і великими затримками RTT доступна смуга пропускання використовується неефективно, тобто канал ніколи не завантажується повністю.
У компанії Riverbed думали приблизно в тому ж напрямку. І оскільки у нас вже є коробки-оптимізатори на вході і виході, то нерозумно не використовувати їх для модифікації TCP-протоколу, щоб уникнути стандартних проблем. Тому оптимізатори вміють не тільки оптимізувати трафік на рівні даних (дедуплікація / стиснення), а й прискорювати транспортний рівень.
Ось ряд режимів, доступних для прискорення TCP:
- режим HighSpeed TCP - тут швидкість досягає максимуму куди швидше, ніж при звичайній роботі з TCP. При втратах він не так низько і не так сильно просідає, як стандартний TCP;
- режим MaxTCP - використовує 100% смуги без уповільнень. Пакет втрачається - уповільнення не відбувається. Однак цей режим вимагає настройки правил якості обслуговування QoS для визначення обмежень доступної смуги пропускання, яку може займати MX-TCP трафік;
- режим SCPS - розроблений спеціально для супутникових каналів зв'язку. Тут смуги не обмежуються, як в MaxTCP. SCPS відмінно адаптується до плаваючих характеристикам супутникових каналів.
оптимізація додатків
Багато додатків «балакучі», тобто можуть відправити до 50 пакетів тоді, коли досить одного. Як я вже говорив, це наслідок проектування під локальні мережі, а не під роботу через канали «далекої» зв'язку. З використанням оптимізаторів число проходів туди-назад зменшується більш ніж в 50 разів.
Ось як це виглядає:
Оптимізатори виступають в ролі прозорих проксі на сьомому рівні для ряду найпоширеніших прикладних протоколів.
Оптимізатор Цода виступає в ролі клієнта по відношенню до сервера. Оптимізатор філії виступає в ролі сервера по відношенню до клієнтів. Таким чином, неефективне, «балакуча» спілкування додатків залишається в локальній мережі. Між оптимізаторами обмін повідомленнями додатки відбувається в більш зручному для каналів зв'язку вигляді - зменшується кількість повідомлень.
Пристрої оптимізації Riverbed вміють прискорювати на сьомому рівні такі прикладні протоколи:
Що цікаво, тут є і шифровані додатки, включаючи зашифрований Citrix і MAPI. При оптимізації шифрованого трафіку не відбувається зниження рівня безпеки.
Приклади прискорення роботи додатків. У реальному мережі прискорення буде залежати від каналу зв'язку. Чим гірше канал зв'язку, тим більших показників прискорення можна досягти.
Типова схема підключення
Оптимізатори Steelhead ставляться перед каналом передачі даних, але до пристроїв шифрування. Для Цодов з особливими вимогами також використовується кластеризація для підвищення надійності плюс балансувальник навантажень Interceptor.
Результат (приклад)
Зелений - WAN-трафік. Синій - LAN-трафік. Без оптимізатора Riverbed вони були б однаковими.
Виділена колонка показує відсоток стиснення по TCP-портів.
лінійки заліза
Потужність може бути розширена ліцензією. Для підвищення продуктивності в ряді випадків потрібно апаратний upgrade. Можливості апргейд в межах платформи показані зеленими стрілочками.
Молодша модель підходить навіть для маленького інтернет-магазину: вона від 1 мегабіта на секунду і 20 каналів. А флагман підтримує до 150 000 одночасних відкритих з'єднань на каналах 1,5 гигабита в секунду. Якщо цього недостатньо, використовується балансувальник Inteceptor. Кластери з балансувальник і оптимізаторів дозволяють працювати з каналом до 40 гігабіт на секунду з відкритим одночасно 1 мільйоном з'єднань.
Скільки коштує по прайсу?
Молодша модель - приблизно від 100 тисяч рублів, пристрій для середніх ЦОД - 1,1 млн рублів, для великих Цодов - від 5,5 млн рублів. При цьому ціна досить сильно змінюється в залежності від конкретних схем використання, плюс можуть бути знижки, тому названі числа суто приблизні, краще уточнюйте поштою (вона є в кінці топіка). Окупність таких рішень для середнього і великого бізнесу прорахувати досить легко, просто прикинувши, що у вас звільниться від 30 до 60% каналу (знову ж, конкретний показник з точністю до 10% я зможу назвати поштою в залежності від типу утилізації каналу), а користувачі не будуть скаржитися на гальма додатків.
Ще елементи Riverbed:
Після того як канал оптимізований описаним способом, ми найчастіше робимо моніторинг та вирішення проблем з конкретними сервісами та обладнанням. На практиці - це цілі детективи. Про них я розповім трохи пізніше. Якщо цікаво - підписуйтесь на корпоративний блог КРОК на Хабре.
Для кого впроваджував конкретно я:
Я не маю права називати всіх замовників, але можу сказати, що рішення Riverbed для оптимізації трафіку використовувалося для:
- п'яти найбільших представників банківського сектора;
- великої золотодобувної компанії;
- великої логістичної компанії;
- ряду компаній менше розміром.