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

В целом, в связи с более широкими требованиями к систем визуального анализа информации и потребностями в части интеграции с источниками данных стали распространяться специализированные решения для ad-hoc анализа данных, такие как Kibana, Grafana и иные. Данные системы могут интегрироваться со специализированными хранилищами временных рядов данных, одним из которых является InfluxDB. Статья расскажет о готовом решении, распространяемом в виде образа Docker, использующем LibVirt API, Grafana и InfluxDB, предназначенном для сбора и анализа параметров исполняющихся VM для гипервизора KVM.

Настройка резервного копирования уверенно занимает одно из важнейших мест в деятельности администратора. В зависимости от задач резервного копирования, типов приложений и вида данных резервное копирование может осуществляться с помощью различных инструментов, таких как rsync, duplicity, rdiff-backup, bacula и других, коих существует огромное множество.

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

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

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

Однако, для открытого пакета shellinabox я обнаружил решение на блоге на немецком языке, которое я и решил довести до нужного мне уровня. В итоге, получился симпатичный контейнер Docker, который можно найти как на GitHub так и на Dockerhub, который решает все необходимые задачи.

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

Apache CloudStack представляет собой универсальную платформу управления средами выполнения виртуальных машин (часто такие продукты именуются “панель управления облаком VPS”). Использование Apache CloudStack (далее, ACS) дает администратору возможность развернуть облако с требуемыми сервисами в короткий срок, а после развертывания эффективно управлять облаком в течение всего жизненного цикла. В рамках данной статьи даются рекомендации по дизайну облака, который может использоваться на практике и подходит для большинства провайдеров публичных облаков, планирующих построение публичных облачных сред малых и средних размеров, обладающих максимальной простотой администрирования и не требующих специальных знаний для отладки и обнаружения проблем. Статья не является пошаговым руководством настройки Apache CloudStack.

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

Облако с описанным в статье дизайном успешно используется для оказания коммерческих услуг по аренде VPS. В рамках облака развернуто хранилище на 16 ТБ, состоящее полностью из SSD накопителей Samsung Pro 850 1TB, организованное в программный RAID6, 176 ядер Xeon E5-2670, 768 GB RAM, сеть на 256 публичных адресов.

В середине 2014 года мы в приняли решение о необходимости переноса услуг публичного сервиса аренды виртуальных машин (далее сервис VPS) с платформы OpenQRM, которая была выбрана на тот момент без должного анализа потребностей клиентов и не отвечала требованиям как к управляемости так и к философии поведения (надо сказать, что разработчики OpenQRM вообще странно подошли к разработке, создав продукт из кучи bash-скриптов, кода на PHP и кучи костылей). В общем, наши пользователи были несчастливы, сервис был так себе и приносил скорее убытки, чем прибыль. Необходимо отметить, что наша дочерняя компания, которая как раз оказывает операторские услуги — небольшая региональная компания и мы не рассматривали создание большого сервиса VPS в тот момент, а основной задачей виделось переход на стабильный и надежный продукт, который бы отвечал следующим требованиям:

• простота в развертывании и настройке для нужд сервиса VPS;
• готовность к использованию и достаточно широкая база пользователей;
• простота в диагностике ошибок;
• удобный пользовательский интерфейс;
• API для управления виртуальными машинами.

Размер инфраструктуры не планировался большим — на тот момент мы рассчитывали использовать 512 — 1024 ГБ RAM, 128 — 256 ядер Xeon E5-2670, 10 — 20 ТБ хранилища, 200+ виртуальных машин. Сервис предполагал предоставление виртуальных машин с непосредственным присвоением публичных IPv4, о поддержке IPv6 речь не шла. В качестве технологии виртуализации мы ориентировались на KVM. Хранилище — классическое NFSv3.