Мультиоблако: новый подход к построению инфраструктуры ИТ

Как и многие технологические тренды, термин «мультиоблако» пришел к нам с Запада. Так называют подход к созданию интегрированной инфраструктуры на базе нескольких облачных провайдеров. Мультиоблако обеспечивает высочайшие уровни доступности и масштабируемости, возможность разместить системы как можно ближе к пользователю, а также устранить технологическую зависимость от одного провайдера. Один из нашумевших примеров — Netflix, использующий одновременно AWS и GCP.

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

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

В идеальной ситуации на новую мультиоблачную инфраструктуру переносятся cloud native-приложения, соответствующие 12 критериям, сформулированным командой Heroku, а лучше — 15 критериям, описанным Кевином Хоффманом. При разработке таких приложений необходимо фокусироваться на возможностях облачных вычислений и особенностях виртуальной инфраструктуры.

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

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

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

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

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

Второй подход — репликация резервных копий СУБД. Этот метод отлично подходит для случаев, когда допустима потеря данных, например, для тестовых сред. При этом для небольших объемов данных может использоваться инструментарий СУБД, а для значительных — отдельные системы резервного копирования.

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

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

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

Первый — использовать один из фреймворков автоматизации управления вычислительной инфраструктурой, например, Ansible, SaltStack, Chef и т.д. В этом случае нам как раз пригодится декларативное описание конфигурации, упоминавшееся выше.

Второй подход, сейчас активно набирающий популярность, заключается в «упаковке» отдельных сервисов в контейнеры. Прообраз технологии появился в Unix-системах больше 10 лет назад, но широко распространяться она стала только в последние годы. С одной стороны, возник спрос, а с другой — добавились некоторые вспомогательные технологии, которые позволяют использовать такой подход в промышленных масштабах. Программных продуктов для реализации этого подхода множество, самые популярные: Docker, rkt, PouchContainer.

Бинарный код и конфигурация контейнера содержатся в образе. Единожды собранный, он будет предсказуемо одинаково работать на всех платформах. Например, собранный и работающий на моем ноутбуке docker-образ будет точно так же работать в вашем ЦОДе или у гиперскейлера, была бы возможность выполнить команду docker run. Немаловажно, что если образ запустился на какой-либо платформе один раз, то он гарантированно запустится во все последующие — нужно только следить за доступностью ресурсов. В этом ключевой момент повторяемости. К сожалению, фреймворки автоматизации не могут гарантировать, что единожды успешно выполненный, например, playbook, точно сработает в следующий раз.

Следует понимать, что один контейнер — это еще не приложение, но процесс. Процессов, как и контейнеров, в мультиоблачной инфраструктуре будет много, они должны будут взаимодействовать как между собой, так и с конечным пользователем (через интернет или внутреннюю сеть). Для запуска приложения, состоящего из множества контейнеров, и управления им, нам потребуется оркестратор, например, Kubernetes, Mesos или Swarm. Он и будет разворачивать сразу несколько контейнеров, контролировать последовательность их запуска и отслеживать их доступность.

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>