Какие могут быть варианты настройки load-balancer \ proxy \ CDN?

Question

[AleksDesker]

Есть сервер, на котором бежит multisite, движок обслуживаюший одновременно 100-200 независимых сайтов. У каждого доменного имени свой хозяин, который заведует настройками DNS. Есть необходимость мигрировать этот движок к другому хостеру, если возможно постепенно, один сайт за другим, отслеживая нагрузку и в дальнейшем есть желание менять эти сервера (IP) не связываясь с сотней веб-мастеров, с которыми необходимо согласовывать смену nameserver-a. Сайты используют https, Lets Encrypt TLS cert, актуально использование CDN.
Можете посоветовать какие-то варианты использования некого middle-man: load-balancer, может каких-то связок от cloudflare load-balancer+CDN или других решений, которые позволят единожды скординировав смену DNS с владельцами домменных имен в дальнейшем управлять ими без их участия, сменить конечный IP если надо и т.п.?

Comments

[smilingcheater]

Способ менять IP для доменов самостоятельно - договориться с владельцами доменов, чтобы они у себя вместо A записи прописали CNAME, которая будет вести на ваш домен (и его поддомены - для каждого сайта - отдельный поддомен), которыми уже будете управлять вы, когда и как вам надо.

[AleksDesker]

smilingcheater, Спасибо. Насколько я помню у некоторых владельцев с этим были трудности, она настаивали использовать именно a-record, но стоит уточнить, возможно стоит подумать над этим варинтом, если других не найдется.

Answer 1

[Евгений Хлебников]

с A-записями вы далеко не уедете, для вашей схемы нужен CNAME, как в комментариях уже написали
И, если будете избавляться от A записей, надо с каждым клиентом прорабатывать отдельно: возможно, им A запись нужна потому, что в их DNS 2-го уровня зоне больше ничего нет (и у них нет других сервисов), а запись необходима для работы txt и прочих записей (например для того чтобы почта ходила). Здесь, как варианты которые можете обсудить с ними:
1. если их DNS провайдер предоставляет услугу хостинга - можно предложить направить их A запись в зоне второго уровня туда, на статический сайт с редиректом на поддомен, который, в свою очередь CNAME-ом смотрит на ваш хостинг
2. предоставить им подобный статический сервис, который вы не будете менять
3. сделать точку входа для A записей, которая не будет меняться, но и не будет содержать приложения - только балансер, направляющий трафик на ваше приложение
Еще возможно, им принципиально важно чтобы ваш сервис был на домене второго уровня. Тогда может помочь перенос с их стороны DNS хостинга на провайдера, поддерживающего ALIAS записи (он же CNAME FLATTENING у CloudFlare) - они позволяют "прописывать" в зоне 2 уровня CNAME (который динамически обновляется и преобразуется по сути в A запись) без A записи
Для переключения
Самый, наверное, простой способ контролируемо переносить на другой хостинг это уникальные таргеты для CNAME
к примеру, клиент1 получает client1.service.name который и прописывает в CNAME у себя
В случае когда нет необходимости разделять клиентов по хостингам, у вас в DNS будет запись *.service.name -> IP хостинга 1
переезжает client13: добавляем client13.service.name -> IP хостинга 2
то есть client13 смотрит на новый хостинг а все остальные - на старый

Не претендую на полноту вариантов, но похожая задача решалась при переезде (и A запись тоже была, но там от нее не избавлялись, ибо чревато переосмыслением продукта и выпиливанием фич)
Постепенное переключение решалось перекидыванием трафика на стороне LB - с помощью настройки proxy protocol. В этом случае весь трафик все равно шел через одну точку входа, но старый хостинг разгружался - клиенты постепенно перекидывались на новый, для тестирования устойчивости и мониторинга нагрузки. А затем была долгая и муторная работа команды суппорта с ожиданием клиентов которые после 10 китайского предупреждения еще не сменили IP у себя в A записях.. та еще история