апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

показать все 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

12.04.2024

На RIGF 2024 обсудили ключевые вопросы цифрового развития России

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2016 / Выпуск №02 (55) / Доставка приложений в корпоративном ЦОДе и облачных средах Часть 1. Выбор ADC

Рубрика: Безопасность

Леонид Шапиро, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M

Доставка приложений в корпоративном ЦОДе и облачных средах
Часть 1. Выбор ADC

Интенсивное развитие центров обработки данных (ЦОД), облачных технологий, рост собственных инфраструктур требуют эффективной доставки приложений и сервисов пользователям (Application Delivery)

Что подразумевает термин «эффективная доставка приложения» с точки зрения ожиданий клиента? В сущности, здесь мы говорим об SLA [1] приложений и о необходимости его обеспечить.

• Во-первых, это высокий уровень производительности, достаточный для повседневной операционной деятельности независимо от способа доступа и типов каналов связи. Мыговорим не только о локальных средах, но и, разумеется, о доступе через линии связи глобальных сетей (WAN).
• Во-вторых, возможность централизованного управления инфраструктурой приложений компании, независимо от ее расположения, будь то корпоративная среда или сервис, предоставляемый из облака.
• В-третьих, соответствие правилам информационной безопасности компании (ИБ). Нетрудно заметить, что ограничения ИБ нередко влияют на производительность иуправляемость системы.
• В-четвертых, эффективность с финансовой точки зрения.

Все это создает существенные сложности, но не означает, что эффективную доставку приложений нельзя реализовать.

Традиционные проблемы при доставке приложений

С какими трудностями приходится столкнуться большинству компаний?

Согласно исследованию, предлагаемому в [2], речь идет о недостатках разработки самого прикладного программного обеспечения, поскольку далеко не всегда разработчиком уделяется должное внимание условиям последующей доставки приложения пользователю, например, используются недостаточно эффективные и надежные протоколы, требующие многократного взаимодействия с сервером. Согласно приведенным опросам [2] лишь пятая часть компаний-разработчиков готова уделить серьезное внимание этой ситуации.

Другим важным ограничением являются задержки сети и недостаточная ее производительность. Это особенно актуально, когда клиенты осуществляют доступ посредством медленных и ненадежных каналов связи, через интернет.

Кроме того, компаниям требуется большое число различных критичных для бизнеса приложений, при этом приложения предъявляют разные требования к инфраструктуре и могут оказывать влияние на работу друг друга.

Растет количество веб-приложений, чья популярность связана не только с тем, что для клиента привычнее единая среда доступа, но и с тем, что нередко поддержка подобных приложений проще ввиду отсутствия необходимости внесения изменений в клиентскую часть при изменениях в серверной. При этом веб-приложения часто оказываются еще больше, чем традиционные, клиент-серверные, подвержены уязвимостям из-за недостаточного внимания к этим вопросам при их разработке. Таким образом, к уязвимостям стека TCP/IP, операционных систем добавляются еще и проблемы, связанные с недостатками веб-приложений.

Обычно возможностей единственного сервера при работе с критическими для бизнеса приложениями недостаточно с точки зрения надежности и доступности, поэтому нередко строятся так называемые фермы серверов. Существенной проблемой может стать избыточная нагрузка на отдельные серверы в составе фермы. Следовательно, необходимо обеспечить масштабирование и правильный выбор сервера при обращении клиента.

Консолидация серверов в рамках единого или небольшого количества ЦОДов дает возможность централизации корпоративной среды, большей ее управляемости и безопасности,что, с одной стороны, снижает совокупную стоимость владения инфраструктурой, а с другой – приводит к более интенсивному использованию каналов связи, которые становятся узким местом. Виртуализация серверной инфраструктуры (IaaS), рабочих мест сотрудников компании (DaaS), программного обеспечения (SaaS), несмотря на свои очевидные плюсы, оказывает существенное влияние на производительность прикладной среды и нагрузку на каналы связи.

Также проблемой становится использование технологий Bring Your Own Device (BYOD) – потребность пользователей применять любые устройства для доступа к корпоративным приложениям. По сути своей, это приводит не только к росту нагрузки на каналы связи, но и к повышению угроз с точки зрения безопасности.

Все эти проблемы возникли не сегодня, однако ввиду стремительного развития потребности в мобильности и BYOD, виртуализации и облачных решений по-прежнему актуальныдля большого числа компаний.

Подходы к решению проблем доставки приложений. Использование ADC

Исторически развитие решений в этой области начинается с середины 90-х годов [2], появление ряда их составных элементов мы видим в составе операционных систем, например, технология NLB появляется в операционной системе Microsoft Windows 2000 [3], а технологии кэширования и того раньше. Появляются контроллеры оптимизации каналов связи глобальных сетей – WAN Optimization Controller (WOC) [4]. Однако все это лишь частные компоненты, которые улучшали положение, но не давали комплексного подхода к доставке приложений. То есть речь не могла идти о комплексном решении, единой системе управления, соответствии требованиям безопасности.

Именно поэтому на смену такому подходу приходят более совершенные средства – контроллеры доставки приложений, Application Delivery Controllers (ADC), чьи функциональные возможности значительно выше.

Контроллеры доставки приложений (ADC) – следующий шаг в развитии решений по распределению нагрузки и ее оптимизации. Они дают возможность не только выполнять базовые задачи балансировки пользовательских запросов между серверами, маршрутизации и перенаправления трафика, но обладают функционалом, позволяющим строить весьма сложные правила этой балансировки. Выбирать оптимальный ее вариант, например, учитывая фактическую нагрузку на серверы, их возможности с точки зрения обработки клиентских запросов и т.п. По сути, список возможных правил у современного ADC должен быть весьма существенным, чтобы обеспечить гибкое и эффективное решение. Кроме этого, в составе ADC должны присутствовать функции, обеспечивающие повышение производительности работы приложений, безопасность, доступность и отказоустойчивость. Например, работа с шифрованным трафиком SSL. Это позволяет существенно снизить нагрузку серверов, которая значительно возрастает при выполнении криптографических операций. ADC также используются для реализации отказоустойчивости распределенных ЦОДов с помощью технологий GSLB. Современные решения на основе ADC предоставляют возможность гарантировать SLA приложений, что особенно важно сейчас с развитием рынка облачных услуг.

Реализация ADC существует в различных форм-факторах: это может быть как аппаратное устройство, так и виртуализованное решение, кроме того, существенную долю рынка внастоящий момент занимают устройства, позволяющие поддерживать большое количество виртуальных балансировщиков, работающих под собственным гипервизором, специально разработанным для наиболее эффективного выполнения этих задач. Как раз такой вариант и позволяет обеспечить строгую изоляцию и возможность соответствия SLA каждого отдельно взятого приложения.

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

Сегодня на российском рынке представлено множество решений такого класса, каждое из которых имеет свои положительные и отрицательные стороны. Наиболее популярные варианты представлены тремя лидерами. Это компании Citrix, F5, Radware. Следует отметить, что именно эти компании являются лидерами и на международном рынке согласно классификации, представленной Gartner [5] (см. рис. 1). Также представлены компании Brocade, Kemp, A10 и ряд других.

Рисунок 1. Gartner Magic Quadrant for ADC 2015

Выбор ADC

На какие аспекты следует ориентироваться при выборе решения в области ADC? Что же требуется от современного ADC-контроллера?

Основные цели следующие: оптимизация стандартных операций, минимизация снижения производительности, предотвращение простоев в работе.

Начнем с базовых функциональных особенностей, которые должны присутствовать в решениях такого типа:

• Гибкие возможности балансировки с 4-7 уровнями модели OSI [6].
• Расширенный функционал проверки работоспособности серверов и приложений.
• Высокая производительность и гарантированный SLA приложений независимо от типа подключения.
• Инструментарии оптимизации трафика.
• Мониторинг работы приложений администратором, отслеживание тенденций с целью предпринять превентивные корректирующие действия в случае снижения качества сервиса.
• Единая централизованная система управления. Интеграция с существующими службами каталога.
• Интеграция с системой безопасности предприятия и соответствие требованиям ИБ.
• Финансовая эффективность решения .

Теперь разберемся с каждым из этих пунктов более подробно.

Современный ADC должен работать не только с основной функциональностью транспортного уровня, но и решать более сложные задачи, учитывая специфику работы прикладного программного обеспечения. Разумеется, ввиду огромного количества используемых приложений сложно разработать готовые шаблоны для всех вариантов, однако должны существовать готовые решения для типовых, наиболее используемых приложений, например SAP, Exchange, Link, SharePoint.

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

Нетрудно заметить, что традиционное развитие ADC начинается с функций балансировки нагрузки. Важным является не только сама возможность выполнения этой задачи наразных уровнях OSI [6], но и умение балансировщика определить работоспособность сервера (healthcheck), на который перенаправляется трафик, причем здесь мы говорим отнюдьне о базовой функциональности. Например, проверка может предусматривать простой ICMP-запрос на сервер. И если сервер ответил, то трафик на него перенаправляется.

Такой вариант оказывается слишком простым и не учитывает неработоспособность конкретного приложения. Стало быть, современный ADC должен предоставлять возможность строить гибкие многокритериальные проверки с использованием логических выражений. Только в этом случае можно говорить об эффективности этого решения.

Необходима возможность гарантирования SLA приложений в соответствии с требованиями организации. Строгая изоляция выделяемых приложениям ресурсов позволит избежать захвата ресурсов одним приложением в ущерб другим. В этой связи стоит рассматривать решения, предлагающие возможности виртуализации ADC, которая может быть реализована как в рамках аппаратного устройства, так и на основе основных промышленных гипервизоров: VMWare vSphere [7], Microsoft Hyper-V [8], KVM [9]. Очевидно, чтокрайне желательно наличие интеграции с системами оркестрации, которое бы позволило в значительной мере упростить развертывание ADC, максимально автоматизировав этот процесс.

В силу стремительного роста облачных решений, массового использования технологий BYOD возникает острая необходимость оптимизации трафика и адаптации его не только дляосновных видов и редакций стандартных интернет-браузеров, а также браузеров мобильных устройств, но и с точки зрения структурных особенностей веб-страниц с тем, чтобы ускорить их загрузку. Ведь далеко не всегда, а точнее, крайне редко можно рассчитывать на то, что разработчики будут уделять серьезное внимание вопросам оптимизации.

Еще одна тенденция – существенное увеличению шифрованного трафика. Это приводит к тому, что серверы приложений вынуждены заниматься не только своей непосредственной работой, но и выполнением криптографических операций, что значительно снижает их производительность, вследствие чего увеличивается количество серверов в ферме. Возможность исполнения процедур шифрования на ADC позволит существенно улучшить ситуацию, уменьшив количество аппаратных устройств и сократив расходы наоборудование. Для этого используемое оборудование должно быть адаптировано для выполнения именно криптографических операций, то есть обладать специализированным модулем, чтобы разгрузить ресурсы процессорной подсистемы. Если объем криптографических операций высок, то для их выполнения целесообразно рассматривать аппаратное решение.

Чрезвычайно важной является возможность превентивного контроля над приложениями и отслеживания тенденций в изменении их работы. Это позволит администратору своевременно реагировать на ухудшение качества обслуживания пользователей. Система должна предоставлять наглядное отображение положения вещей в реальном времени (см. рис. 2).

Рисунок 2. Мониторинг производительности приложений

Здесь мы видим, что любое изменение производительности работы приложения будет немедленно показано администратору, который сможет определить причину возникновения ухудшения и предпринять корректирующие действия. Наиболее интересным вариантом является модуль Application Performance Monitor (APM), предлагаемый компанией Radware [10].

Современная система управления должна обеспечивать возможность централизованного контроля за всеми компонентами решения. Большая часть производителей ADC предлагает поэтапное развитие их инфраструктуры, то есть если сегодня требуется только базовый вариант балансировки, то можно использовать только его, не обращаясь к другим возможностям. Однако развитие инфраструктуры подразумевает рост требований к ней, соответственно, при этом приобретается и устанавливается дополнительный компонент. Стало быть, им придется управлять. Крайне желательно, чтобы это делалось в рамках единой системы, при этом необходима интеграция с существующими службами каталогов, чтопозволит использовать уже имеющуюся базу данных пользователей.

Все большую популярность приобретают веб-приложения. Традиционно балансировка нагрузки началась именно с веб-серверов, и здесь важно понимать, что веб-сервер –потенциальная цель для злоумышленника. Следовательно, надо обеспечить его защиту от типовых атак на уязвимости веб-приложений, таких как OWASP TOP-10 [11], но и от DDoS-атак. Здесь ситуацию существенно облегчает веб Application Firewall (WAF). Ближе всего к веб-серверу находится ADC. Так почему бы не реализовать этот функционал в его составе?

Некоторые производители именно так и поступили, что, несомненно, очень удобно потребителю. Интегрированный модуль WAF позволяет обеспечить защиту от атак, при этом нетребует параллельной системы управления.

Крайне важно обеспечить защиту от DDoS-атак. Многие производители предлагают ее в составе ADC. С одной стороны, это очень полезная функция, но есть и другая сторона медали. Дело в том, что любой ADC потенциально уязвим, поскольку имеет IP-конфигурацию, то есть потенциально может быть успешно атакован. Поэтому, с моей точки зрения, реализация защиты от DDoS на ADC возможна как дополнение к уже установленным системам защиты на периметре или в облаке, и гораздо существеннее становится возможность интеграции ADC с системами отражения DDoS-атак и других типов злонамеренных действий. То есть при обнаружении атаки, например модулем WAF, ADC должен уведомить пограничное устройство отражения атак с тем, чтобы данная атака начала блокироваться еще на периметре. Такая схема интеграции реализована Radware в составе решения Attack Mitigation System (AMS) [12].

С отражением DDoS-атак можно познакомиться в цикле статьей «БИТа» [13]. Таким образом, эффективная схема внедрения ADC-решения с точки зрения безопасности длякорпоративного или облачного ЦОДа может выглядеть так, как это показано на рис. 3.

Рисунок 3. Интеграция ADC с системой отражения атак

Экономическая эффективность конкретного решения определяется в том числе и схемой его лицензирования, предлагаемой производителями. Серьезной проблемой оказывается необходимость замены оборудования, если мы говорим об аппаратных ADC, с ростом требований его мощности. Это приводит к дополнительным расходам, которых хотелось быизбежать. В этом плане схема «плати по мере роста» (Pay-As-You-Grow) оказывается существенно предпочтительнее. Не требуется замена оборудования, а обновление достигается спомощью приобретения новой лицензии. То есть, сравнивая ADC с экономической точки зрения, имеет смысл посчитать TCO для каждого из них.

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

1. Соглашение об уровне услуг – https://ru.wikipedia.org/wiki/Соглашение_об_уровне_услуг.
2. Traditional Application & Service Delivery Challenges – http://www.ashtonmetzler.com/Traditional%20App%20Delivery%20Challenges%20V2.0.pdf.
3. Network Load Balancing, Windows 2000 Advanced Server – https://msdn.microsoft.com/en-us/library/bb742454.aspx.
4. Ann Bednarz What makes a WAN optimization controller? – http://www.networkworld.com/article/2282040/lan-wan/what-makes-a-wan-optimization-controller-.html.
5. Gartner, Inc. (NYSE: IT) is the world’s leading information technology research and advisory company – www.gartner.com.
6. The OSI Model’s Seven Layers Defined and Functions Explained – https://support.microsoft.com/en-us/kb/103884.
7. vSphere и vSphere with Operations Management – http://www.vmware.com/ru/products/vsphere/features.
8. Обзор Hyper-V – https://technet.microsoft.com/ru-ru/library/hh831531.aspx.
9. Kernel Virtual Machine – http://www.linux-kvm.org/page/Main_Page.
10. OWASP Top Ten Project – https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.
11. Application Monitoring Tools – Features and Benefits – https://www.radware.com/Products/APM-Features.
12. DDoS Attack Prevention Security Solutions & Intrusion Prevention Systems – https://www.radware.com/Solutions/Security.
13. Шапиро Л. Атаки DDoS. Часть 1. Война объявлена... // «БИТ», №5, 2015 г. – С. 28-31 (http://bit.samag.ru/archive/article/1504).
    Шапиро Л. Атаки DDoS. Часть 2. Арсенал противника// «БИТ», №6, 2015 г. – С. 24-27 (http://bit.samag.ru/archive/article/1521).
    Шапиро Л. Атаки DDoS. Часть 3. Разведка. // «БИТ», №7, 2015 г. – С. 12-15 (http://bit.samag.ru/archive/article/1536).
    Шапиро Л. Атаки DDoS. Часть 4. Военные хитрости. // «БИТ», №8, 2015 г. – С. 22-23 (http://bit.samag.ru/archive/article/1559).
    Шапиро Л. Атаки DDoS. Часть 5. Основные принципы выбора системы защиты от DDoS-атак. // «БИТ», №9, 2015 г. – С. 34-38 (http://bit.samag.ru/archive/article/1580).

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи