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

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

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

В случае потребления дискового пространства прогнозирование можно возложить на вашего провайдера, опережать потребление — это его задача. Однако в случае вычислительных экземпляров объем фактической «работы», которая ими выполняется, в значительной мере зависит от размера/класса экземпляра, а также использования ресурсов приложением (которое тоже, разумеется, зависит от размера/класса экземпляра). Кроме обычных причин для сбора метрической информации по мощностям облака, существуют и другие причины для организации сбора метрик и оповещения о событиях:

  • Производительность любого экземпляра и хранилища может изменяться по мере того, как поставщик облачного сервиса перераспределяет мощности с целью адаптации архитектуры к повышению нагрузки.
  • Даже если поставщик предоставляет соглашения об уровне обслуживания (SLA), очень важно знать, когда на ваших экземплярах или в хранилищах происходят сбои. Полезное правило: верь, что инфраструктура доступна… но проверяй. Возможно, развертывание новых мощностей в облаке выполняется быстро, но не мгновенно. Время запуска нового экземпляра стоит измерить.
  • Хотя облачные хранилища могут автоматически масштабироваться в соответствии с потреблением дискового пространства, скорость выборки данных из хранилища не гарантирована, Как и в случае с ограничениями базы данных по интенсивности дискового ввода/вывода, пропускная способность хранилища может стать фактором, влияющим на мощности, и ее также следует измерить, Это относится и к операциям ввода/вывода с любыми «локальными» хранилищами, выполняемыми вашими вычислительными узлами.

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

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