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

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

ИТ-команды всё больше полагаются на облачную инфраструктуру для решения своих задач, поэтому её безопасность и доступность становятся приоритетными.

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

Что произойдёт, если доступ к текущему облачному провайдеру внезапно прервётся? Что делать, если потребуется быстро перейти к другому облачному провайдеру из-за правительственных санкций или других геополитических факторов?

С другой стороны, каждый кризис — это время возможностей. Как не упустить момент, когда можно захватить свою долю зарубежного рынка, имея всё необходимое для этого: зарубежные счета, востребованный на этом рынке продукт и другие ресурсы?

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

Зачем нужно дублирование облачной инфраструктуры

Поскольку диапазон возможностей ИТ-команды напрямую зависит от бюджета, который выделяется бизнесом, сначала рассмотрим этот вопрос с точки зрения руководителей компаний.

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

Финансовые риски

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

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

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

Репутационные риски

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

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

Риск долгого простоя

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

Например:

• изучение альтернативных облачных провайдеров, сравнение стоимости их услуг и надёжности, оценка соответствия их местным нормам защиты данных. Этим вопросам необходимо уделить должное внимание, поскольку ещё одного шанса у бизнеса может и не быть;

• поиск новых членов команды с опытом работы в выбранном облаке. Конечно, можно обучить текущих сотрудников, но необходимые компетенции нужны уже сейчас;

• адаптация продукта под особенности нового облака;

• потенциальный поиск полностью новой команды и её погружение в проект. Все мы люди и хотим стабильного дохода, поэтому текущие сотрудники, видя вокруг себя панику, отсутствие «плана Б» и туманное будущее компании, наверняка захотят найти себе более надёжное место.
  

Изменение процессов

Скорее всего, зона ответственности сотрудников существенно расширится. При отсутствии чётко отлаженного disaster recovery-плана всем придётся быстро адаптироваться и делать что-то «сверх» своих компетенций и/или рабочего времени.

Отсутствие необходимых знаний

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

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

Ручное развёртывание инфраструктуры

Ручное поднятие и настройка инфраструктуры сопровождаются целым рядом проблем.

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

Если инфраструктура плохо документирована, а изначально её настраивали Петя и Вася, которые уволились три года назад, потребуется дополнительное время, чтобы разобраться в системе и корректно воспроизвести её в новом облаке.

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

Адаптация приложений

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

Это требует времени и может привести к появлению «костылей», которые в дальнейшем создадут дополнительные проблемы.

Интеграция с существующими системами

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

Для решения этой проблемы потребуется время, а само решение может оказаться «костыльным» со всеми вытекающими последствиями.

Потеря данных

Неполное резервное копирование или его полное отсутствие и хранение бэкапов только в текущем облаке — комбинация «непростительных» ошибок.

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

Изменение CI/CD-процессов

При смене облачного провайдера придётся менять и CI/CD-процессы. Это снова означает временные затраты и необходимость использовать дополнительные решения.

Как подготовиться к возможной смене облака

1. Выбрать подходящее альтернативное облако

При выборе альтернативного облачного провайдера необходимо обратить внимание на следующие параметры:

• наличие нескольких зон доступности;

• наличие необходимых managed-сервисов, их версии и особенности. Например, в Google Cloud у Memorystore for Redis отказоустойчивость реализована в виде реплик — с опцией чтения или без неё — и автоматического failover. В Yandex Cloud high availability реализуется в виде системы Redis Sentinel или Redis Cluster;

• наличие сервисов безопасности — Anti-DDoS и т. п.;

• наличие необходимых дистрибутивов ОС;

• наличие Terraform-провайдеров;

• наличие развёрнутой документации со ссылками на официальную документацию используемых сервисов;

• варианты тарифов поддержки;

• надёжность. Здесь можно учитывать мнение коллег («сарафанку», профильные сайты и форумы), а также обращать внимание на страницу с клиентами и партнёрами облака;

• соответствие местным нормам защиты данных. Если речь идёт о РФ — соответствие 152-ФЗ, ГОСТ Р;

• стоимость услуг, варианты оплаты, наличие дисконтов и скидок.
  

Если есть необходимость быстро и безопасно переехать в российское облако, компания Nixys может с этим помочь.

2. Описать инфраструктуру как код

Подход Infrastructure as Code (IaC) имеет ряд существенных преимуществ.

Во-первых, можно быстро и автоматически создать инфраструктуру в новом облаке, протестировать её и при необходимости так же быстро и автоматически внести изменения или временно удалить ресурсы, чтобы избежать переплат.

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

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

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

Наконец, процессы изменения инфраструктуры можно удобно встраивать в CI/CD-пайплайны: вместо сложных bash-скриптов достаточно применить новые конфигурации одной командой. 

Какие инструменты можно использовать

Традиционно существует два подхода к IaC: декларативный и императивный.

В качестве примеров рассмотрим Terraform и Ansible — два инструмента для управления инфраструктурой в виде кода, имеющие свои отличительные особенности:

1. Особенности Terraform:

• предоставляет декларативный язык для определения инфраструктуры, который позволяет описать желаемое состояние инфраструктуры без необходимости задавать конкретные шаги для её настройки; 

• поддерживает широкий диапазон провайдеров, включая AWS, Google Cloud, Microsoft Azure, Yandex Cloud, Selectel и другие, что позволяет использовать один и тот же язык для управления инфраструктурой в различных облачных окружениях;

• поддерживает планирование изменений инфраструктуры, что позволяет убедиться в том, что изменения будут безопасными и не приведут к нежелательным результатам; 

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

Рассмотрим несколько примеров того, как отличаются модули на примере Google Cloud и Yandex Cloud:

1. High Availability Redis:

Google Cloud

terraform {
  backend "gcs" {
    bucket      = "my-project-tf-state"
    prefix      = "terraform/gcp/services/redis-ha/state"
    credentials = "my-project-cred.json"
  }

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "= 4.58.0"
    }
  }
}

provider "google" {
  credentials = file(var.cred_path)
  project     = var.project
  region      = var.region
}

resource "google_redis_instance" "redis" {
  name               = var.redis_instance_name
  tier               = "STANDARD_HA"
  authorized_network = data.google_compute_network.redis-network.id

  auth_enabled   = "true"
  redis_version  = var.redis_version

  memory_size_gb = var.redis_memory_size

  replica_count           = 2
  location_id             = var.gke_cluster_zone_1
  alternative_location_id = var.gke_cluster_zone_2
}

Yandex Cloud

terraform {
  backend "s3" {
    endpoint                    = "storage.yandexcloud.net"
    bucket                      = "my-project-tf-state"
    region                      = "ru-central1"
    key                         = "redis.tfstate"
    shared_credentials_file     = "storage-cred"

    skip_region_validation      = true
    skip_credentials_validation = true
  }

  required_providers {
    yandex = {
      source  = "yandex-cloud/yandex"
      version = "= 0.88.0"
    }
  }
}

provider "yandex" {
  service_account_key_file = "key.json"
  cloud_id                 = var.cloud_id
  folder_id                = var.folder_id
  zone                     = var.default_zone
}

resource "yandex_mdb_redis_cluster" "redis" {
  name               = var.redis_instance_name
  environment        = "PRODUCTION"
  network_id         = data.yandex_vpc_network.redis.network_id

  config {
    password = random_password.redis_exporter.result
    version  = "6.2"
  }

  resources {
    resource_preset_id = var.instance_type
    disk_size          = var.disk_size
  }

  host {
    zone      = data.yandex_vpc_subnet.redis.zone1
    subnet_id = data.yandex_vpc_subnet.redis.subnet_id
  }

  host {
    zone      = data.yandex_vpc_subnet.redis.zone2
    subnet_id = data.yandex_vpc_subnet.redis.subnet_id
  }

  host {
    zone      = data.yandex_vpc_subnet.redis.zone3
    subnet_id = data.yandex_vpc_subnet.redis.subnet_id
  }
}

Далее в примерах блоки backend, required_providers и описание провайдера опустим, поскольку они меняться не будут. При этом необходимо внимательно указывать версию провайдера — от неё зависит описание сущностей.

2. Правило firewall:

Google Cloud

resource "google_compute_firewall" "openvpn-firewall" {
  name    = "openvpn-firewall-external"
  network = module.vpc_myvpc.network_self_link

  allow {
    protocol = "udp"
    ports    = ["1194"]
  }

  target_tags   = ["openvpn"]

  source_ranges = ["0.0.0.0/0"]
}

Yandex Cloud

resource "yandex_vpc_security_group" " openvpn-firewall " {
  name       = "openvpn-firewall-external"
  network_id = yandex_vpc_network.myvpc.id

  ingress {
    protocol       = "UDP"
    port           = 1194
    description    = "openvpn"
    v4_cidr_blocks = ["0.0.0.0/0"]
  }
}

3.Группа нод кластера Kubernetes:

Google Cloud

resource "google_container_node_pool" "pool" {
  name     = var.node_pool_name
  cluster  = module.private_gke.cluster_name

  initial_node_count = var.count_node_per_zone
  node_locations     = var.pool_node_zones

  autoscaling {
    min_node_count = var.min_node_count
    max_node_count = var.max_node_count
  }
  node_config {
    disk_size_gb = var.disk_size_gb
    disk_type    = var.disk_type
    machine_type = var.machine_type
  }

  upgrade_settings {
    max_surge       = 1
    max_unavailable = 0
  }

  management {
    auto_repair  = true
    auto_upgrade = false
  }
}

Yandex Cloud

resource "yandex_kubernetes_node_group" "group" {
  name        = var.node_pool_name
  cluster_id  = yandex_kubernetes_cluster.my_cluster.cluster_id

  allocation_policy {
    location {
      zone = "ru-central1-a"
    }
    location {
      zone = "ru-central1-b"
    }
    location {
      zone = "ru-central1-c"
    }
  }

  scale_policy {
    auto_scale {
      min     = var.min_node_count
      max     = var.max_node_count
      initial = var.initial_node_count

    }
  }

  instance_template {
    platform_id = "standard-v2"

    network_interface {
      nat                = true
      subnet_ids         = [id_1, id_2, id_3]
    }

    resources {
      memory = 8
      cores  = 2
    }

    boot_disk {
      size = var.disk_size_gb
      type = var.disk_type
    }

    scheduling_policy {
      preemptible = false
    }
  }

  deploy_policy {
    max_expansion   = 1
    max_unavailable = 0
  }

  maintenance_policy {
    auto_repair  = true
    auto_upgrade = false
  }
}

Как видно из примеров, параметры интуитивно понятны, и большинство из них легко сопоставимы у разных провайдеров. Поэтому переход с одного облака на другое хоть и займёт определённое время, всё же не будет продолжительным.

Также следует учитывать, что различаться будут только специфические для конкретного облака ресурсы. Например, модули для развёртывания приложения в кластер Kubernetes будут полностью одинаковыми.

Что касается Ansible, здесь можно говорить о полной универсальности, если ОС и дистрибутив полностью совпадают.

Можно ли использовать Terraform в РФ

HashiCorp присоединилась к санкциям и запретила доступ к своим продуктам пользователям из РФ.

Однако выход есть: у некоторых облаков — Yandex, VK, Croc — есть свои зеркала, откуда можно скачать дистрибутив инструмента и установить необходимые провайдеры.

3. Настроить сбор и хранение бэкапов в альтернативном хранилище

Этот пункт напрямую не относится к инфраструктуре, однако в контексте утраты доступа к текущему облаку не сказать о нём нельзя.

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

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

В компании НИКСИС используется собственная разработка — nxs-backup. Новая версия продукта была представлена ранее, подробнее о ней рассказано здесь.

4. Перенести публичные Docker-образы в личный хаб

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

Хранение публичных Docker-образов в личном хабе может быть критически важным в случае блокировки, удаления или утраты доступа к публичным хранилищам, таким как Docker Hub или Quay.io. Это может произойти, например, из-за изменения правил использования сервиса. Одним из инструментов, позволяющих хранить образы в личном хабе, является Harbor.

Harbor — инструмент с открытым исходным кодом для управления контейнерными образами и Helm-чартами. Он позволяет создавать и управлять личными репозиториями на основе ролевой модели доступа, сканировать образы на уязвимости и выполнять другие задачи.

5. Описать приложения как код

Если приложения запущены в Kubernetes, создайте для них Helm-чарты. Они облегчат и ускорят деплой в новый кластер, позволят быстро обновлять и откатывать приложения, что особенно полезно при тестировании работы приложений в новой инфраструктуре.

Для этих целей также был разработан собственный универсальный Helm-чарт. Подробнее о его использовании на проектах рассказано здесь.

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

6. Подготовить отдельную ветку CI/CD для альтернативного облака

Создайте отдельную ветку в Git-репозитории с CI/CD-пайплайном для альтернативного облака и поддерживайте её в актуальном состоянии.

Переход с одного облачного провайдера на другой влияет на конфигурацию инфраструктуры. Поэтому необходимо проанализировать настройки текущего CI/CD-пайплайна и внести необходимые корректировки.

Ниже приведены некоторые возможные изменения:

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

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

Необходимые изменения следует задокументировать в README.

Таким образом, на работу разработчиков смена облака не повлияет, а значит, временные затраты на доставку и тестирование изменений продукта будут меньше.

Что получаем в результате

Подведём итоги и посмотрим, какие преимущества получает бизнес и его ИТ-команда в случае утраты доступа к текущей инфраструктуре.

Для бизнеса:

• минимизация простоя, то есть финансовых издержек и репутационных потерь;

• сохранение критически важных клиентских данных;

• сокращение расходов на работу команды, обслуживающей инфраструктуру.
  

Дополнительным преимуществом становятся возможности для расширения зоны влияния на зарубежных рынках.

Для ИТ-команды:

• минимизация человеческого фактора, то есть ошибок при ручных манипуляциях с новой инфраструктурой;

• возможность быстрого отката или обновления;

• единообразие в развёртывании компонентов инфраструктуры и приложений;

• ускорение тестирования работоспособности продукта в новых средах;

• упрощение дальнейшего управления инфраструктурой и её поддержки.
  

Цена подготовки:

У подхода заблаговременного дублирования инфраструктуры есть преимущества, однако за них приходится платить:

• затратами на наращивание компетенций сотрудников;

• затратами на поиск альтернативных решений, описание инфраструктуры и приложений как кода;

• затратами на тестирование заготовок.
  

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