Отказоусточивый сервер Обсуждение

Тема в разделе "Linux, Freebsd, *nix", создана пользователем RoBoT, 23 сен 2015.

  1. RoBoT

    RoBoT Студент

    Репутация

    155 / 54


    Коллеги, доброго дня.

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

    Для данной структуры мы выбрали следующую связку

    Сервер №1 - Веб сервер:
    Процессор: 4х2000
    ОЗУ: 8Гб
    Диски SAS 120 ГБ
    Предустановленный софт: nginx + php5-fpm + шифрование директории веб-сервера.

    Сервер №2 - Master mySQL
    Процессор: 2х2000
    ОЗУ: 4Гб
    Диски SAS: 20 ГБ
    Предустановленный софт: Percona XtraDB Cluster

    Сервер №3 - slave mySQL:
    Процессор: 2х2000
    ОЗУ: 4Гб
    Диски SAS: 20Гб
    Предустановленный софт: Percona XtraDB Cluster


    Все серверы будут связаны между собой средствами приватных ключей.
    На всех серверах будут заблокированы все порты из вне.
    Сервер №1 открытый порт - 443 (открыт из вне)
    Сервер №2, №3 открытый порт - 3306 (открыт локально в нутри сети ДЦ)

    Доступ к сервера будет происходить через защищенную сеть ДЦ провайдера.


    Существует несколько камней с которыми мы столкнулись в процессе проектирования и хотелось бы консультации умных людей в кибер мире )
    Данные хранимые в БД частично будут персональными, согласно новому закону данные должны хранится шифрованными в самой БД, сам mySQL имеет методы mcrypt с помощью которых имеется возможность шифровать данные блочным шифром AES, но в данном случае у нас происходят небольшие накладки в хранении ключа шифрования, ведь в php он должен передаватся вместе с запросом, а так же участвовать при дешифровке строки, имеются некоторые проблемы с хранение ключа, изначально задумывалось запереть ключ в изолированной директории в файле key.php, но идея достаточно плавающая.

    Вопрос: Как при использовании данной структуры возможно осуществить полное шифрование данных как самой БД так и общения между серверами?

     
  2. RoBoT

    RoBoT Студент

    Репутация

    155 / 54


    Спустя 2 месяца, ответа так и не было :)
    Что же, путем вычислений и методов тестирования мы пришли к структуре 3х серверов, основанных на модной в наше время структуре VDC.
    3 не зависимых сервера общаются только внутри локалки, один сервер смотрит во внешнюю сеть.

    1 сервер запущен через балансировщик, остальные сервера представляют собой кластер mySQL.
    Все порты заблокированы, разрешен только 80 порт для работы с самим сервисом. Остальные скрыты в локалку и во вне запрещены.
    Для безопасности данных используется независимое шифрование блочным симметричным шифром AES.
    Общение между БД и сервером настроено по одноразовому токену, каждый запрос должен сопровождаться уникальным одноразовым токеном, все токены генерируются по алгоритму предоставленному Google.Com, аналог Google Auth.

     
  3. Insallah

    Insallah Продам учётку! ;)

    Репутация

    631 / 331


    Ой, я провтыкал тему. От слова вообще. О_о

     
  4. RoBoT

    RoBoT Студент

    Репутация

    155 / 54


    Так же хотелось бы добавить, что использовать встроенный метод шифрования в mySQL - mcrypt не рекомендуется.
    Причина: При включенном хранении событий и логировании запросов, ключ можно будет скомпроментировать по событиям БД, т.к передается ключ в самом запросе.

     
  5. X-ray

    X-ray Шустроган

    Репутация

    1.163 / 2.552


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

     
  6. RoBoT

    RoBoT Студент

    Репутация

    155 / 54


    БД соединены в кластер.
    В своих начинаниях решили заюзать Percona XtraDB Cluster.

    По тестам заметно просаживание скорости работы БД. Но для сохранности данных терпимо.
    Для работы с нодами БД используется 1 виртуальный айпи разделенный между двумя серверами, для балансировки решили заюзать HAProxy(Но смотрим в сторону nginx, имеется такая возможность), пока в кластере всего 2 сервера, планируется поднять 3 для бекапа.

    На данный момент мы держимся следующей логики работы с БД:
    Запросы, приходящие на порт 3306, HAProxy раскидывает по Round Robin между первой и второй нодами
    То, что приходит на 3307, проксируется только на первую ноду. При этом если первая нода вдруг упадет, запросы перейдут на указанную вторую ноду (как упоминалось планируется поднять третью ноду для бекапа и как резервную)
    При этом для качественной работы мы используем логику распределенного чтения - записи. Сервер распределяет запросы так чтобы запросы на чтение шли через соединение с первой нодой, а запросы на запись направлялись на вторую ноду.

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

     
    Последнее редактирование: 8 дек 2015
  7. Lucky

    Lucky Философ

    Репутация

    64 / 561


    паришся ты слишком много и делаешь ненужные костыли. Чтобы сервер был отказаустойчив необходимо сделать одну маленькую хрень, а именно бэкапить нужные данные на удаленную машину почаще. ПРОФИТ!

     
  8. RoBoT

    RoBoT Студент

    Репутация

    155 / 54


    Это не отказоустойчивый сервер(Хотя раньше по неопытности мы считали так же). Это называется халтура. Прод запускать в такой конфигурации это навредить самому себе.

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

     
    Последнее редактирование: 8 дек 2015
  9. X-ray

    X-ray Шустроган

    Репутация

    1.163 / 2.552


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

     
  10. Habilis

    Habilis Прииикииинь! ;)

    Репутация

    291 / 227


    Хэккеров развелось...

     
    Metamorphosis нравится это.
  11. RoBoT

    RoBoT Студент

    Репутация

    155 / 54


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

    Мы такие вещи пресекаем не зависимыми снапшотами файловой структуры с временными метками и весом файла раз в час. А так же каждый архив сопровождаем чек суммами. Такая подлянки возможна, но минимальна :)

    Под автоматизацией сервера я подразумевал не восстановление из бекапов, а восстановление работоспособного состояния сервисов.

    Допустим на данный момент некий набор скриптов может искать решения для ошибок в работе nginx и fpm, а так же исправлять failed start попытки на лету.

    А восстановление бекапов это строго ручная работа, тут без обсуждений.

     
  12. Insallah

    Insallah Продам учётку! ;)

    Репутация

    631 / 331


    Гм. С базами мудрено. Берём две базы. Master и Slave. Между ними настраиваем репликацию. И не нужно в кластер сводить. Кластера любят иногда быть нестабильными.
    Если нагрузки не сильно пиковые — возможно имеет смысл сервера арендовать в облаках Амазона? До определённого уровня нагрузок архитектура на Амазоновских облаках обходится заметно дешевле чем стандартные методы.

     
  13. RoBoT

    RoBoT Студент

    Репутация

    155 / 54


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

     
  14. iv777

    iv777 Школьник

    Репутация

    15 / 16


    Это все хорошо. Все эти зеркала - рейды, кластеры. Главное, чтобы не в одном месте
    А то видел один раз, как в с 100 м от прекрасного отказоустойчивого сервера поработали отбойным молотком...
    Там все было и рейд и не рейд...

     
  15. Igor Nko

    Igor Nko Школьник

    Репутация

    0 / 6


    У Амазона можно арендовать отдельно и нужную СУБД с высоким уровнем доступности и построить самостоятельно кластер.
    Если бизнес так критичен к простоям СУБД (ее доступности) то каким образом будет обрабатываться сценарий, когда доступ к Амазону будет ограничен или же частично ограничен ?
    Что-то подсказывает, что должна быть локальная базейка на такие блекауты.
    Кстати у меня за несколько лет использования Амазона было несколько длительных (3-4 часа) периодов не доступности к их сервисам.
    При этом я видел те же проблемы с разных локаций (Америка, Европа).
    И были другие приколы, когда доступ к серверам по SSH и RDP был, но на самих серверах не было нормально доступа к внешним ресурсам...тоже часов 5-6 в год набегает.
    Поэтому ваше решение имеет (не зависящие от вас) риски, которые стоит учитывать :)

     
  16. jchjch

    jchjch Новичок

    Репутация

    0 / 0


    Вебсервер всего один - для реальной отказоустойчивости это не годится. Дублировать нужно всё.
    Возьмите два одинаковых VDS, на каждом и веб и БД, фс синхронизировать через drbd или просто кроном ежеминутно, база в master-master репликации, переключение на резервный сервер через DNS.

     
  17. RoBoT

    RoBoT Студент

    Репутация

    155 / 54


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

    Поднятиe master-master БД на каждой из нод так же весьма сомнительная затея в плане отказоустойчивости и целостности данных БД, с этой связкой есть много подводных камней которые к сожалению очень сильно ограничивают в использовании, я не говорю об вводе еще одного мастера в эту связку при необходимости... master-slave намного проще в обслуживании и в возможностях будущего шардирования... Предложение синхронизации фс по крону, достаточно дурацкое, вы гоняли между нодами хотябы гб данных в минуту? Ладно с настроенным rsync при одновременной записи на несколько серверов, но по крону? Вы серьезно?

    Насчет drbd если память не изменяет, то для реализации схемы "primary - primary" мне необходимы кластерные фс(тот же GFS2), ни один из известных мне хостеров не поддерживает возможности предоставить верхний уровень ФС как форматированную кластерную ФС, есть конечно исключение такие как OverlayFS, но к сожалению снова упираемся в ограничения SELinux, т.к. они не совместимы.

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

    Переключение на резервный сервер по средствам dns - весьма скверно, эта задача входит и в обычный балансировщик HAProxy позволяя перенаправить веса и оставить в обслуживании один сервер. Насчет дублирование всего - не целесобразно. Веб сервер выполняет работу API, необходимость горизонтального масштабирования необходима только при росте нагрузки до 87%, тогда вводить второй сервер и вводить его в область весов HAProxy дело 15 минут, когда существует запас по мощности в пределах 55% необходимости в горизонтальном масштабировании нет, достаточно резервного сервера.

    План на развертывание сервера при необходимости горизонтального масштабирования:
    1. Железка в стойку
    2. Разворот снапшота фс
    3. Синхронизация исполняемых скриптов
    4. Монтирование amazon каталога контента
    5. Тестирование портов
    6. Автоматический ввод в HAProxy
    время ~15 минут, при условии развертывания снапшота из сетевого хранилища.