В моей компании возникла потребность в установке кластерного сервера (так это называется?). У нас есть хостинг, арендованный за границей, и поэтому мы имеем ограниченный доступ к фактическому оборудованию, но у нас есть полная свобода и мы не ограничены финансовыми ресурсами (при условии, что мы, конечно, избегаем излишков - нет необходимости в 300 серверах, если 3 могут справиться с этим) .
Мы - международное онлайн-издательство, предлагающее бесплатные читаемые в Интернете книги. Это означает, что у нас есть тонна статического содержимого - в основном много-много гигабайт флэш-документов. Недавно мы обновили серверную ОС до CentOS x64 и изменили серверное программное обеспечение с Apache на Nginx (для статического контента) + Apache. Однако возникли некоторые проблемы, и мы столкнулись с неожиданными простоями, которые сильно нам повредили, даже если они длились всего пару часов.
Мои мысли о настройке кластера были следующие:
- сервер 1: наша текущая база данных MySQL.
- сервер 2, сервер 3, сервер 4: наше приложение, то есть наш PHP-код на Apache
- сервер 4: только статический контент (изображения от 5 до 3 МБ, PDF-файлы от 5 до 100 МБ, флеш-файлы от 200 до 20 МБ и т. д.) на базе Cherokee
Я считаю, что эта настройка поможет нам избежать простоев в случае отказа одного из трех серверов приложений, помимо распределения нагрузки между тремя серверами, в отличие от того времени, когда все (статическое + приложение DB +) было на одном компьютере.
Я хотел бы от вас, ветераны, несколько полезных ссылок о распределении нагрузки на сервер, подсказок и советов по этой проблеме и предложенной мной выше настройке. У меня ограниченный опыт работы с Apache в качестве разработчика PHP, и не более того, так что если кто-нибудь может предложить я был бы очень признателен за любую ценную информацию об их настройках или опыте работы с различным оборудованием / программным обеспечением.
Кроме того, какова правильная терминология? Облако? Кластер? Любые другие термины, о которых мне следует знать. Пожалуйста, будьте осторожны, я только начинаю вступать в серверный мир.
Спасибо
Изменить: новый план выглядит следующим образом, дайте мне знать, что вы думаете:
Кластер приложений:
- 3 сервера под управлением Nginx (или Cherokee) и Apache с PHP. Nginx будет обрабатывать запросы статического контента на том же сервере (CSS, JS, эскизы, спрайты, изображения).
- Поскольку в настоящее время у нас есть 2 веб-сайта с довольно большим трафиком (один с высоким уровнем обновлений БД, другой с высоким уровнем обслуживания статического контента), мы думали разместить оба на этом сервере приложений.
- Два приложения будут иметь два балансировщика нагрузки для распределения трафика между тремя серверами. Серверы будут идентичными клонами и впоследствии легко масштабируемы.
Кластер базы данных
- Два сервера под управлением MySQL, клоны. Балансировщик нагрузки. Резервные копии будут делаться на самих себе, поскольку маловероятно, что оба они умрут одновременно. Оба приложения в кластере приложений будут использовать этот кластер - одно будет выполнять среднюю нагрузку чтения, а другое - высокую нагрузку чтения-записи.
Статический кластер
- Два сервера исключительно со статическим контентом, в основном просто для хранения тысяч файлов PDF, Zip и Flash. Нет резервного копирования, невозможно выполнить эффективно. Серверы - это резервные копии друг друга. Этот статический кластер будет обслуживать более крупный статический контент для обоих приложений в кластере приложений.
Это реально? Что бы вы посоветовали и не посоветуете? Что бы вы добавили?
Я думаю, что uesp довольно хорошо освещал общие вопросы. Чтобы решить, что вы собираетесь делать в своем случае, вам нужно сесть и подумать о нескольких вещах:
- Какова текущая нагрузка на каждый из этих компонентов? Какова прогнозируемая будущая нагрузка?
- С какими сценариями сбоев вы хотите справиться? Что стало причиной вашей последней неудачи?
Первые вопросы говорят вам о минимальном количестве серверов, которое вам понадобится на каждом уровне, чтобы иметь работающий сайт.
Второй вопрос говорит вам, сколько оборудования вы действительно хотите иметь, чтобы ваш сайт продолжал работать. Изложив режимы отказа, вы обнаружите, что вам нужно будет учитывать не только серверы: брандмауэры, восходящие интернет-соединения, генераторы, физическое местоположение и многое другое. Вам также нужно будет решить такие вещи, как вызовы администраторов для устранения сбоев серверов в 3 часа ночи и мониторинг, необходимый для того, чтобы разбудить администратора и сообщить им, что что-то сломалось. Если ваш предыдущий сбой был вызван ошибкой конфигурации или программирования, подумайте о промежуточной среде между разработкой и производством, чтобы тестирование проводилось после того, как программисты завершат свои изменения, и до того, как изменения вступят в силу.
Несколько общих вещей, которые я узнал за эти годы:
- Видеть этот вопрос список хороших книг по производительности, масштабированию и высокой доступности сайтов.
- «Кластер» - правильный термин. Вы используете несколько компьютеров для обслуживания одного сайта в попытке повысить доступность. Вы также можете использовать кластер для ссылки на определенные части вашей установки: например, серверы 2 + 3 + 4 будут вашим кластером приложений.
- Есть ли причины, по которым у вас есть резервирование только на уровне приложения? А как насчет MySQL и статического контента? Тем более, что у вас относительно большой статический контент, посмотрите, какую пропускную способность вы можете обслуживать N одновременно работающих пользователей, если это необходимо. Что произойдет, если сервер MySQL выйдет из строя или если на сервере №4 неисправен диск?
- Если вы перемещаете все с одной машины, начните с малого, если вы не против потратить больше, чем вам нужно. Например, при переходе с 1 на 3 сервера я обнаружил больший, чем ожидалось, прирост производительности в аналогичной ситуации. После того, как вы разделитесь на несколько серверов, вы можете обнаружить, что новое узкое место находится в другой области.
- Планируя масштабирование сейчас, не забывайте полностью о возможном масштабировании в будущем. Немного передовой мысли и дизайна сейчас могут сэкономить ваше время в будущем. Например, у вас сейчас есть один статический сервер, а вы хотите - несколько серверов в год, или несколько серверов расположены географически.
- Подумайте о создании сценариев, которые помогут настроить определенные типы серверов ... делая это вручную, каждый из них устаревает, и вы всегда забываете один шаг. Я сделал это недавно и хотел бы сделать это с самого начала. Запуск одного сценария, который автоматически выполняет 50 шагов установки за несколько минут, в конечном итоге сэкономит вам много времени.
- По мере того как вы получаете больше серверов, вероятность возникновения аппаратного сбоя становится выше. Спланируйте это и сыграйте в игру «что, если»: что, если на сервере X произойдет сбой жесткого диска? Что мы потеряем? Как долго сайт будет отсутствовать? Сколько времени нужно, чтобы это исправить? и т.д...