Средства и системы мониторинга в облачных сервисах

На протяжении всей этой книги я говорил о средствах управления облачной инфраструктурой и системах ее мониторинга как о критически важных инструментах для нормального функционирования инфраструктуры компании в облачной среде. Я управляю одной такой компанией, enStratus (http://www.enstratus.com/), но есть и множество других систем, предназначенных для той же цели, в том числе — RightScale (http://www.rightscale.com/) и Morph (http://mor.ph/). Какая из этих компаний лучше всего подойдет именно вам, зависит от вашего бюджета, от типов приложений, которыми вы управляете, и какие компоненты вашей инфраструктуры для вас наиболее важны.

Какой бы инструмент вы ни подобрали для себя, он, как минимум, должен обладать следующими возможностями (все три упомянутых мной компании их предоставляют):

± планирование изменений в объемах мощностей при развертывании ваших приложений;

± мониторинг процесса развертывания с целью выявления избыточных потребностей и случаев падения потребностей ниже нормального уровня;

± автоматическая настройка доступных мощностей на основании неожиданных всплесков и падений активности в зависимости от текущих потребностей.

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

Если у вас нет возможностей или желания платить за программное обеспечение от сторонних производителей, вы можете разработать и развернуть собственную систему мониторинга. Архитектуру системы мониторинга иллюстрирует рис. 7.3.

Рис. 7.3. Общая архитектура системы мониторинга состояния облачной инфраструктуры

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

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

са для сбора основных системных данных о ресурсах, включая CPU, RAM, а также остальные данные, связанные с протоколом SNMP. В дополнение, сервер приложений Java поддерживает интерфейсы JMX (Java Management eXtensions)1, которые позволяют запрашивать информацию о производительности ваших виртуальных машин Java.

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

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

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

Процесс выделения ресурсов в облачной среде

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

1 Технология JMX была разработана для упрощения разработки систем мониторинга и управления. Причем управлять можно фактически чем угодно — лишь бы это было написано на Java. Это может быть микроустройство типа считывателя отпечатка или система, включающая тысячи машин, каждая из которых предоставляет определенные сервисы.

Подробнее см. http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/, http://www.java-course.ru/articles/jmx.html, https://secure.wikimedia.org/wikipedia/en/wiki/Java_Management_Extensions. — Прим. перев.

услуг внешнего управления (MSP), вам обычно необходимо сначала оформить заказ на покупку, который должен быть одобрен финансовым отделом или бухгалтерией вашей компании. Финансовый отдел одобряет заказ, основываясь на бюджете вашей компании, после чего ваш заказ отправляется поставщику. Вы не можете, например, потратить на новый сервер сумму $3000 до тех пор, пока эта трата не будет одобрена финансовым отделом вашей компании.

С другой стороны, в инфраструктуре AWS ничто не мешает вам запускать команду ec2-run-instances каждый раз, когда вам требуется новый экземпляр EC2 модели extra-large, и тратить на это примерно $7000 в течение года. Каждый, кто имеет возможность запускать новые экземпляры или менять критерии масштабирования ваших средств управления облачной средой, имеет полные права поставки облачных ресурсов. IT-менеджер не должен получать никаких одобрений от финансового отдела, он просто меняет конфигурационные параметры программы, доступа к которой финансовый отдел может и не иметь.

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100