Как правильно организовать инфраструктуру (выделенные серверы, облака и пр.)?

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

Текущая инфраструктура:
1. Выделенный сервер в LeaseWeb (Intel Quad-Core Xeon X3440, 8 GB RAM, 500 GB SATA). PHP-FPM, nginx, MySQL, memcached. База за год выросла до 5 ГБ. В час-пик 200-300 запросов в секунду. Рост где-то 15% в месяц. Производительности уже немного не хватает (load average стабильно больше двух), но связано скорее с плохой настройкой MySQL и наличием еще одного проекта на том же сервере.
2. Выделенный сервер для бэкапов (куда раз в сутки переливаются файлы).
3. Два выделенных сервера для проксирования запросов (основной и запасной). Используется nginx. Можно назвать балансировщиками, но по факту нужны только для скрытия IP и принятия на себя удара при DDoS (что случается довольно часто). Одновременно не используются. Начинается атака на основной прокси, включаем платный CloudFlare со ссылкой на запасной прокси.
4. Почтовый сервер на VDS, через который проходит вся исходящая почта. По факту нужен опять же только для скрытия IP основного сервера.

Хочется как-то всё это оптимизировать, настроить репликацию (чтобы в случае отказа основного сервера иметь на руках актуальную копию БД), включить HTTPS. Я разработчик, а не администратор. Никогда подобным не занимался (ни репликой, ни https). В штате администратора нет, поэтому переезд на мне. Нанимать никого не хочется исключительно из-за вопросов безопасности и конфиденциальности.

Основные вопросы:
1. Нужно ли избавляться от зоопарка серверов? Ресурсы на всех кроме основного используются крайне неэффективно, но прокси и почтовый должны быть изолированы, потому что их часто атакуют. А сервер бэкапов не должен упасть вместе с основным. Критично, чтобы IP были из разных подсетей, потому что атакующие часто проверяют соседние адреса (к сожалению, не во всех ДЦ это возможно). Стоит ли смотреть на облака?
2. Как правильно организовать проксирование (скрытие IP, защита основного сервера от DoS)? Осложняется необходимостью ввода https и передачей реальных IP на основной сервер (при периодическом добавлении CloudFlare в качестве третьего звена).

Поделитесь, пожалуйста, опытом и дайте несколько советов.
  • Вопрос задан
  • 776 просмотров
Пригласить эксперта
Ответы на вопрос 1
athacker
@athacker
Я бы вынес всё, кроме основного сервака, на виртуалки. Легче маневрировать, легче масштабировать, если что. "Ещё один сервис" -- тоже вынес бы на какую-нибудь потустороннюю виртуалку.

Неясна необходимость ещё одного выделенного сервера под бэкапы. У вас база всего 5 Гб, полный дамп даже на домашнем интернете можно 1 раз в час скачивать без всяких проблем, зачем ещё один выделенный сервак?

Резюмируя: облака -- они таки для того и сделаны, чтобы масштабироваться по-быстрому. Например, в каком-нибудь амазоне поднять пару виртуалок с проксями в разных ДЦ (Там по географии можно выбрать ДЦ. Есть Штаты, Германия, Британия, ЮВА). Мало будет пары -- поднять ещё несколько. Там есть функция Auto Scaling, которая количеством проксей будет рулить автоматически. Есть тонкость -- при реально мощном DDoSе можно автоматически смасштабироваться на очень много денег :-) Так что учёт, контроль и мониторинг -- это наше всё.

Построить туннели от проксей (IPsec, OpenVPN, whatever) до бэкэнд-серверов. Я бы делал на IPsec.

Бэкапный сервер перепрофилировтаь в полноценный бэкенд. Почтовый сервер, как я уже говорил выше -- на виртуалку и куда-нибудь подальше. Почтовых серверов можно сделать более одного, по той же схеме, что и проксей -- в нескольких регионах на виртуалках (для гарантии получения IP-шников из разных подсетей). Связь почты с бэкендами -- тоже только по VPN, по серым адресам. Все сервисы на бэкендах, кроме SSH -- повесить на серые IP-шники туннелей.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы