Перенос проектов между ЦОДами. Часть 2

Apr 9, 2019 01:09 · 526 words · 3 minutes read ЦОД Миграции Проект

С чего начать и что делать?

Определиться с требованиями:

  • выделить роли контейнеров
  • весь service-discovery должен проходить через контейнеры-фронты
  • все конфиги приложение должно получать через env переменные или dot.env файлы
  • доступ к ресурсам только через haproxy или фронты
База данных Percona

Необходимо было получить реплику БД в нашем проде, откуда бы смогли перетащить данные в наш dev и встроить обновление данных в нашу ферму бд. БД в Нижнем Новгороде: 600GB данных, 4 Kq/s. Сервера в НН с бд страшно с ними что-то делать, так как он может не подняться. Чтобы получить реплику, мы подцепили наш сервер обычным слейвом, в обход Percona xctradb. Почему так? Потому что для полноценной интеграции в кластер, необходимо было перезагрузить инстанс Percona. 600 Gb данных переливались примерно 3 дня, так как канал между цодами НН и Урал у нас ограничен. 600Gb на zfs превратились в 400Gb. К этой реплике в ЕКБ мы подключили percona кластер в ЕКБ на zfs, и уже с него мы снимали zfs снэпшоты, для отправки в dev. Так у нас появилась БД в нашем дев окружении.

Sphinx

Когда у нас появились данные, то получить из него индексы для сфинкса не так уж сложно. У нас уже был собран пакет со sphinx необходимой версии. Поэтому все свелось к настройке параметров индексации данных их БД в поисковые индексы. Полная индексация sphinx занимает около 6 часов.

Openstack Swift

Самая тяжелая часть приложения. 20ТБ статики, которую необходимо перенести из НН в ЕКБ. Swift оперирует следующими понятиями: - object - наименьшая еденица информации - файл с картинкой и тд - container - хранилище групп объектов. Напоминает папку с файлами - ring - группа инстансов swift

Как работала раздача статики:

  • нужно раздавать картинок, либо кропы картинок
  • поднят nginx, в котором настроена большая кэшзона на 350GB для статики
  • при cache miss запрос уходит в swift, результат складывается в cache
  • при отсутствии картинки в swift, предполагается что это запрос картинки на кроп
  • запрос уходит на сервис ресайза, итог ресайза складывается в специальный контейнер swift и отдается в stdout
  • результат кропа сохрянеятся в кэшзону

Что сделали:

  • добавили инстанс swift в ЕКБ к кольцу серверов в НН
  • поставили максимальный вес для нового инстанса swift, чтобы новые картинки сохранялись туда
  • попробовали перелить данные средствами swift - медленно

Проблема в том, что расположение файлов на файловой системе не соответсвует контейнерам. То есть нельзя по расположению объекта на файловой системе понять, к какому контейнеру он относится. Пришлось запускать rsync -rv и перекачивать все данные. Переливка заняла примерно 14 дней. Вроде все работает, файлы сохраняются, раздаются.

Memcached

Для отказоустойчивости принято поднимать несколько инстансов memcache. В нашем случае ребята использовали 2 memcached, ip адреса которых были захардкожены в коде.

Тут может быть несколько вариантов организации доступа к memcached.

  1. Поднимаем haproxy и через него балансируем запросы, добавляем health чеки. 1 инстанс мастер, другой backup
  2. Используем шардирование ключей по нескольким инстансам (twemproxy, mcrouter, dynomite)

Мы решили попробовать пойти по 2му варианту, но: twemproxy не умеет отдавать правильный ответ на команду version; mcrouter имеет очень много зависимостей и сложно собирается под arch; с dynomite тоже возникли некоторые проблемы.

Было решено использовать 1 жирный memcached и ходить в него через haproxy.

PHP7 + laravel
PHP56

#####Сети - схема работы сети - картинка - переключение

Наиболее полезные инструменты
  • ngrep