Назад | Перейти на главную страницу

Масштабирование настройки кластера серверов

Я занимаюсь перестройкой веб-сайта, который в настоящее время посещает около 4 миллионов + посетителей в месяц (и в последнее время эта цифра растет). В настоящее время он управляется и размещается сторонней компанией, но мы отказываемся от них, поэтому мне нужно разработать хостинг.

Подумываю построить небольшой кластер (вероятно, на Линоде):

Сам WP запускает W3 Total Cache с Xcache, я рассматриваю CDN для изображений и других статических файлов, заголовки кеша уже используются для этих статических файлов ...

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

В двух словах: сработает ли эта установка? Было бы это эффективно? Я никогда раньше не создавал ничего подобного, поэтому хочу убедиться, что я что-то не упускаю.

Для справки: новостной сайт. Мы публикуем статьи в нескольких разделах, в некоторых СМИ, и посетители могут комментировать статьи, подписываться на нашу рассылку и т. Д.

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

  • Я не знаю затрат на балансировщики нагрузки linode, но обнаружил, что мне нравится контролировать конфигурацию общего VPS с HAProxy или NGINX для балансировки нагрузки (я выбрал HAproxy).

  • Убедитесь, что у вас достаточно оперативной памяти. К сожалению, публичные предложения, которые я нашел до сих пор, не позволяют вам регулировать количество RAM и HDD (мне нужно больше RAM, но не так много HDD. Ну ладно).

  • Убедитесь, что ваш VPS постоянный. Вы не хотите терять данные (особенно для MySQL), запущенные на VPS, если он выключен или аппаратный сбой. Это документация MySQL для EC2, но применимы некоторые из тех же концепций).

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

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

  • Если вы выполняете развертывание на нескольких серверах с балансировкой нагрузки (2 или более серверов приложений), имейте «главный» сервер, с которого выполняется резервное копирование rsync для обновления кода. Это упрощает процесс разработки (вывести мастер из схемы балансировки нагрузки, убедиться, что подчиненные устройства не синхронизируются со старым мастером, передать код мастеру, убедиться, что все работает должным образом, снова включить rsyncing от главного к подчиненным, затем добавить мастера обратно в схему балансировки нагрузки).

Я уверен, что есть еще кое-что, но настройка, описанная в вопросе, кажется хорошей.

Эта настройка очень похожа на наши кластеры веб-серверов, которые мы используем. Мы используем апстримы Nginx на нашем «балансировочном» сервере для передачи запросов на наши веб-серверы. Я не понимаю, почему ваша вышеуказанная конфигурация не будет работать, и она позволит вам расширяться по горизонтали по мере необходимости.

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

Есть ли у вас в настоящее время резервная копия / хранилище или вы используете RAID для резервирования? Вы можете рассмотреть NAS для моментальных снимков / резервного копирования. Просто мысль.

Вы заставляете меня задуматься об этом глубже, у меня под контролем несколько машин Linode (и Rackspace тоже).

Мой личный сайт работает как ваш план:

  • Плагин W3TC (с хорошей интеграцией с CDN, я вижу, откуда взялась эта идея)
  • PHP / fpm
  • NGINX (1.2)
  • MariaDB 5.2

У меня есть больше сервисов, слишком несвязанных, tracd (edgewall) за nginx в качестве восходящего потока, а также экземпляр couchdb dev.

И все это на линоде 768Мб (второй по низу). Он обрабатывает до 50 соединений в секунду с memcached и дисковым кешем (без APC или CDN). Плагин кеширования увеличивает скорость от 5 до 50 / с (самый большой фрагмент - MariaDB).

Что касается HAPROXY, у меня тоже есть один из них, работающий на Linode. Кстати, в поиске места для стойки уступает Linode, поскольку вы не можете выбрать свое географическое положение из одной и той же учетной записи (у вас может быть 2 учетных записи в нас и за ее пределами). Кроме того, их интерфейс не выглядит таким гладким, как у Linode.

Что касается масштабирования MariaDB, я не считаю это простым, запуск двух мастеров - большая головная боль, чтобы поддерживать их синхронизацию. Классический путь, который я выберу, - это настроить главный сервер и несколько подчиненных (возможно, на узел). Затем в haproxy вы группируете их вместе в режиме TCP, но между вашей БД и HAPROXY я бы поставил mysql-proxy между ними, чтобы убедиться, что записи отправляются на правильный главный узел, вы можете запрограммировать это в LUA. Дополнительным преимуществом является то, что создание подключений к mysql значительно сокращается. Одна большая проблема с производительностью пропала, каждое соединение mysql занимает не менее 5 МБ из того, что я испытал здесь.

Это по-прежнему дает вам единственную точку отказа - главный сервер mysql.

Для этого вы можете использовать подход мастер-мастер со вторым мастером, который нигде напрямую не используется, если только первый не выйдет из строя. Я считаю, что Mysql DB является самым большим ограничивающим фактором при создании больших избыточных кластеров. couchDB намного проще в этом аспекте, но это решение NOSQL ...

Самое главное, что я бы сделал иначе, это то, что я бы отказался от Apache, он вам действительно не нужен, так как PHP / fpm + nginx есть. Поэтому я бы использовал nginx не в качестве кеша, а в качестве внешнего сервера. Apache съест ваш Linode на завтрак по сравнению с тем, что nginx может доставить на Linode ...

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

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

  • Обязательно используйте как минимум два LoadBalancer, использование одного LoadBalancer - единственная точка отказа
  • Используйте кластерную файловую систему (gfs / OCFS2), чтобы быть уверенным, что у вас есть одна копия / версия кода, работающая в вашем кластере, в противном случае вам нужно будет переводить свой веб-сайт в режим обслуживания каждый раз, когда вам нужно будет добавлять новый код. или сделайте некоторые обновления, пока изменения не будут применены ко всем вашим узлам кластера (и все же вы можете забыть обновить один из них)

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

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

При этом вы МОЖЕТЕ заставить многоадресную рассылку работать по ссылке openvpn (подсказка)

поддержка одноадресной рассылки для haproxy ограничивается двумя узлами, контролирующими 1 VIP-адрес.