Добрый день,я в тупике.Я собираюсь открывать портал на 20000 пользователей с кучей сервисов.Все касательно софта,CMS и прочих аспектов программирования уже решено.
Попробую описать на примере yahoo
Допустим мой сайт называется www.site.ru
сначала я запускаю пять сервисов,прописываю через домены третьего уровня
1) games.site.ru
2) rabota.site.ru
3) molotok.site.ru
4) blog.site.ru
5) forum.site.ru
Каждый из этих сервисов написан с нуля,и каждый устанавливается на отдельный недорогой сервер.
А сам основной сайт www.site.ru устанавливается тоже на отдельный более мощный сервер.Базы пользователей линкуются между собой,то есть пользователь бродит по сайту не замечая переходит с сервера на сервер,залогинившись единожды.Все тяжелое,в том числе и бекап будетхраниться на внешнем дисковом массиве.Сервера между собой свзяаны по гигабитной сети.
На всех серверах установлен лицензионный RedHat 32 битный
В оптимале мне нужно,чтобы допустим когда сервер games.site.ru будет загружен на 100%,а rabota.site.ru на 30 нагрузка распределялась равномерным способом между ними,то есть получается как бы кластер распределения нагрузки (LB)
Но это же получается совершенно раздельные системы?с разными базами,данными,причем динамично обновляемыми,стоит ли в таком случае ставить кластер?Пока сильно смотрю в сторону Linux Virtual Server и вот этой статьи http://www.opennet.me/docs/RUS/webcluster/index.html
Что вы думаете,заранее спасибо
LOL думаем.
Думаю вам нужно нанять толкового системного администратора.
>Думаю вам нужно нанять толкового системного администратора.он есть, я ведь не спрашиваю как,я спрашиваю стоит ли?общую схему я вам нарисовал,если есть дополнительные вопросы буду рад ответить
Почему тогда не спросите у него? Или это он предложил такую "замечательную" схему?
Статья на которую вы ссылаетесь давно устарела, хотя некоторые идеи конечно можно почерпнуть. А вообще хорошо спроектировать HA можно, только учтя особенности задачи. Например, если программа использует сессии в файлах, как стандартный пых, то придется выносить это в общее rw хранилище, желательно с нормальными локами. А если использует БД, то нужда в подобном отпадает и ряд проблем исчезает.
В общем случае предложил бы так
1. Независимые БД разнести по разным мускульным серверам, причем каждый из них в отдельный openvz/vserver контейнер ибо мускул не умеет себя толком ограничивать. Физически все это может жить как на одном сервере, так и на нескольких. Для каждого независимого мускула желательно несколько слейвов с репликацией. Приложения должны уметь распределять запросы чтения/записи дабы не записать с дуру в слейв вместо мастера.
2. Основную обработку почты вынести в отдельный контейнер, на остальных MTA только перенаправляют на него. Также отдельный сервер под DNS.
3. Веб приложения делать на основе fast-cgi, в крайнем случае apache+mod_чего_вы_там_юзаете. Исключение наверное для пыха, как самого тупорылого с точки зрения fcgi языка, для него eaccelerator+все_в_один_файл+mod_php.
4. В качестве балансировщика веб нагрузки использовать nginx(или lighttpd), заодно им же осуществлять кеширование и отдачу статики. Это будет основная точка входа. При большом количестве машин можно поставить несколько nginx серверов, а перед ними железный LB или DNS round robin.
5. Как можно больше общих файловых ресурсов монтировать в ro. Разделяемый rw рано или поздно приведет к проблемам. Если правильно спланировать приложения, то нужды в нем не будет.Подобная схема позволит свободно наращивать физические мощности и гибко менять нагрузку на каждый из компонентов, а не только на сайты целиком. Какая-то веб-задача(сайт может делится на отдельные задачи, хотя для конечного пользователя выглядит как одно целое) стала требовать больше ресурсов - увеличиваем количество соответствующих ей fcgi процессов и/или мускульных серверов. Нагрузка упала - сокращаем, дабы передать ресурсы более нагруженным задачам.
именно он,я конечно в прошлом тоже занимался админкой,сейчас я проджект менеджер,он предолжил,я поверил,но проверил
Чтобы дисскусия стала поинтересней сделаю уточнения
1)PHP использует БД
2)сайт будет очень динамичным,будут новости,игры,маркет итд
3)одно из обязательных условий проекта хендовер пользователя,то есть пользовател должен бродить по сайту не замечая этого,один сервис должен передавать его другому.Ну как на мейл ру,залогиновшись единожды,он может проверить почту,пообщать в своем мире,поиграть игры итд
4)сайт будет как минимум трехязычным
5) DNS на отдельном сервере
6) балансировщик будет ngnix а за ним уже апач
7) будет DNS round robin.Осталось дело за IP адресамиТеперь вопросы которые возникли у меня после вашего ответа,буду очень признателен если ответите
1)что вы подразумеваете под независимыми БД? про виртуализацию и слейв-мастер мне ясно
2)как можно научить приложения распределять запросы чтения/записи,подбросьте идею))
3)что есть отдельный контейнер?это отдельный виртуальный сервер?если есть время прошу вас поподробнее про <<Основную обработку почты вынести в отдельный контейнер>>
4)а в чем преимущество отдельного fastcgi по сравнению с апач+mod_fastcgi или mod_fcgid?
5)PHP eaccelerator+все_в_один_файл+mod_php. вы подразумеваете мои программисты под боком говорят что это для теоретиков и крайне неудобно))
6)Что значит <<Как можно больше общих файловых ресурсов монтировать в ro.>>пока вроде все.Буду вам очень признателен за помощь и дальнейшие комментарии
посоветовались подумали и почитали и решили отказаться от ДНС Раунд робин,так как эта технология неэффективна и может использоваться только в смешанном варианте с другими, так как каждый провайдер имеет в своем распоряжении кэширующие DNS сервера, которые сводят на нет все плюсы.
новый вопрос
я в сильно затуплении,скажем так,....не понимаю в чем разница в построении кластера с использованием LVS+heartbeat либо же DRBD+heartbeat (возможно это тупой вопрос,поэтому извиняйте)
drbd не масштабируется(а маштабируемость понадобиться) а LVS хорош для распределения запросов на обслуживание.
Однако я не представляю алгоритма учитывающего верность данных на каждом сервере. Ведь именно на правильные и актуальные данные нужно отправлять клиентов. Проблема еще усугубляется и тем что сайт будет очень диномично обновляемым причем информация будет самой разной,видео,фото,музыка,новости,текст,итд.Выход внешнее хранилище???что делать?
>новый вопрос
>я в сильно затуплении,скажем так,....не понимаю в чем разница в построении кластера
>с использованием LVS+heartbeat либо же DRBD+heartbeat (возможно это тупой вопрос,поэтому извиняйте)
>
>drbd не масштабируется(а маштабируемость понадобиться) а LVS хорош для распределения запросов на
>обслуживание.
>Однако я не представляю алгоритма учитывающего верность данных на каждом сервере. Ведь
>именно на правильные и актуальные данные нужно отправлять клиентов. Проблема еще
>усугубляется и тем что сайт будет очень диномично обновляемым причем информация
>будет самой разной,видео,фото,музыка,новости,текст,итд.Выход внешнее хранилище???что делать?возьмите нгинкс, сразу уменьшите затраты на железо, но надо будет нарастить памяти, обять таки почему редхат 32 битный? надо 64 чтобы держал много памяти.
Сказать честно у меня крутиться на одном сервере тр и проекта в общей сложности на 60 тысяч человек в месяц, средняя посещаемость в день 10 тыщ уников.
Схема примерно такая.
Сервер 2 юнита, двухпроцессорная мать от интеля или супермикро, 2 проца по 4 ядра, 16 гигов памяти, y акаждый сайт свой винт сас, на базу данных отдельный винт сас, логи на отдельном винте тоже.
Программная начинка примерно такая, фронтенд нгинкс, через него отдается вся статика, в виде картинок, джсок, цсс и прочее, так же он проксит на фронтенд, фроентент в виде апаач с мод_пхп, отдает только динамику, к пхп прикручен еакселератор(зенд оптимайзер не смог вместе с еакселератором одновременно сделать), к апачу прикручен мод_рпаф, так как есть кое что зависящее от айпишника клиента.
С запуском нгинкса нагрузка на сервер снизилась в 20 раз.
У вас 20 тысяч онлайн или вообще всего?
>[оверквотинг удален]
> я в сильно затуплении,скажем так,....не понимаю в чем разница в построении кластера
> с использованием LVS+heartbeat либо же DRBD+heartbeat (возможно это тупой вопрос,поэтому
> извиняйте)
> drbd не масштабируется(а маштабируемость понадобиться) а LVS хорош для распределения запросов
> на обслуживание.
> Однако я не представляю алгоритма учитывающего верность данных на каждом сервере. Ведь
> именно на правильные и актуальные данные нужно отправлять клиентов. Проблема еще
> усугубляется и тем что сайт будет очень диномично обновляемым причем информация
> будет самой разной,видео,фото,музыка,новости,текст,итд.Выход внешнее хранилище???что
> делать?В доках на сайте редхата это все подробно расписано, зовется трехуровневая модель - лоад-балансер LVS рутеры (активный, бэкапный, мониторинг веб-серверов рутером через сервис nanny) -> веб-сервера c gfs2 -> HA кластер, общий сторадж (активный и бэкапный через дрбд, раздает или как NAS через nfs или как SAN через iscsi).
Если гфс2 то обязательно кластер менеджер, fenced device, иначе гфс станет колом на всех нодах.
дрбд может масштабироваться через stacked интерфейсы на три и больше нод (и даже делать балансировку в режиме active/active), но будут большие проблемы с мониторингом и сплитбрэйнами.