Для начала небольшой ликбез, о том как вообще устроено у нас все и как работает. Для моих читателей, не работающих в ИТ, постараюсь максимально подробно и просто описать такие страшные вещи, как AWS, AZ, DC/OS и Docker.

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

Проще говоря, если вам нужна маленькая база данных на MySQL или Oracle, вы, вместо того чтобы установить все сами (заказать сервер, поставить ОС, поставить туда СУБД, наладить резервное копирование, мониторинг и прочее), заходите на прикольный веб портал, кликаете по нужной СУБД, выбираете размер, идете за кофе, и, когда вы вернетесь, база данных будет готова и ждать дальнейших распоряжений.

У AWS сейчас сотня различных сервисов, от виртуальных серверов и СУБД до сопровождаемых (не вами, что самое прекрасное) очередей сообщений, кластеров для анализа BigData и даже удаленные рабочие столы и CDN.

Для того, чтобы предоставлять вам определенное удобство управления и планирования ресурсов, Амазон создал модель регионов и “зон доступности” (далее AZ).

Регион - определенная географическая область, на которой Амазон предлагает свои услуги. Может считаться как отдельный город, штат или страна. Регионы именуются по стране или географии, “области” и порядковому номеру. В тех же США у Амазона 4 региона - Северная Вирджиния, Огайо, Северная Калифорния и Орегон. Эти регионы именуются как us-east-1, us-east-2, us-west-1 и, ВНЕЗАПНО, us-west-2. Регионы есть и в Европе, например Ирландия (eu-west-1) и Франкфурт (eu-central-1). Делается это для географического удобства (если вы сидите в Амстердаме, то до сервера в Лондоне добраться быстрее, чем до сервера в Австралии) и для соблюдения законов в странах, где вы хотите вести бизнес. Каждый регион состоит из нескольких AZ.
AZ (availability zone, зона доступности) - это один или несколько ЦОДов (центров обработки данных), которые работают независимо друг от друга, но обладают высокоскоростным соединением между собой. Делается это также для отказоустойчивости - если один из AZ придет в негодность, у вас есть еще 2 (или даже больше) ЦОДа.

Теперь немного технических деталей. Когда вы создали аккаунт на AWS и привязали к нему свою кредитку (Амазон берет плату по поминутной тарификации использования их услуг), вы создаете VPC (virtual private cloud) - этакий “свой” ЦОД внутри ЦОД Амазона, привязанный к определенному региону. Серверы и базы данных в дальнейшем будут ставиться как раз на этот самый VPC. Внутри VPC вы создаете “подсети” (subnets), которые живут внутри вашего VPC и привязываются к определенной AZ.

Да, это может звучать сложно, поэтому перечитайте этот пост несколько раз ну или сходите на сайт AWS и прочитайте все из первоисточника.
Вся эта информация важна, потому что из нее следует первая проблема, с которой я столкнулся.

Когда вы создаете VPC вы указываете большую сеть (до нескольких десятков тысяч IP адресов). А когда вы создаете подсеть, то в ней вы задаете сеть поменьше, которая в свою очередь является частью большой сети.

Так вот мои прекрасные коллеги в регионе с 3 AZ сделали 3 подсети - 2 маленьких (не знаю зачем) и 1 большую (ЗАЧЕМ?!), в которой и “сидит” бОльшая часть нашей инфраструктуры. Помните, что подсеть привязана к AZ? Первая проблема в том, что если эта самая AZ отвалится, то и 80% нашей инфраструктуры повалится вслед за ней. Люблю своих коллег.

Теперь к моей задаче - мне нужно развернуть отдельный кластер DC/OS для так называемого “тулинга” - ряда небольших (или больших) систем, которые помогают нашим разработчикам и бизнесу делать свое дело. Под тулинг можно подвести системы мониторинга, логгирования, несколько велосипедов, написанных нашими силами, TeamCity (система сборки, тестирования и развертывания ПО) и прочее.