kiltum (kiltum) wrote,
kiltum
kiltum

Мы делали, делали и наконец приделали ...

В общем, мы вчера запустили в свободный полет то, что положено сделать по первому этапу "школьного проекта". Так как мне запрещено разворачивать главный калибр против некоторых товарищей (да уже и отпало такое желание), то расскажу, как все там крутится внутри. Вдруг кому интересно :)


Итак, для начала берем Н (нет, Н мало, М) хороших и однотипных серверов. Нагрузка будет в основном на память, процессоры и сеть, поэтому заморачиваемся только ими. Дисковой подсистемой не заморачивается в том смысле, что для наших целей хватит обычного встроенного на мамку рейда. Те сервера, которые будут заниматься сборкой и компиляцией, собраны на 5м рейде, а те, которые являются веб-мордами - на 1м.

Сервера берем хорошие и фирменные. В нашем случае - Dell. Нет, фирменные ломаются примерно также, как и самосборные, но "фирменность" дает уверенность в том, что поломанные железки будут заменены быстро. Сервера 1U, внутри 2 ксеончика и 16Гигов памяти. Ну и 4 диска. Подчеркиваю, разница между серверами только в уровне рейда. В остальном они одинаковые.

Ставим на них CentOS 5.3 x86_64. После установки из центоси выкусываем калеными клещами все, окромя ядра и ssh. После выкусывания ставим туда OpenVZ и удаляем родное ядро. Теперь сервер стал хост-машиной. Проверяем еще раз отсутствие в хост-машине всяких лишних пакетов и переходим к следующему этапу.

Сетевой этап заключается в том, что мы прописываем на машинах виртуальные интерфейсы. Что бы их можно было поднять-опустить командами типа ifup eth0:5 & ifdown eth0:5. Все созданные виртуальные машины будут иметь внутренние адреса из 10й подсетки. Никаких "честных" адресов. Попутно свободными интерфейсами (любой уважающий себя сервер имеет как миниум 2 сетевухи) соединяем сервера между собой напрямую.

Зачем так сделано? Во-первых, безопасность. Выставлять просто так виртуалки в инет можно, но лучше не надо. Все мы человеки и если на какую-нить виртуалку проберется гадость, то даже открыв порт и попытавшись связаться с авторами, она обломится. Во-вторых, в-третих и в десятых она же. Из минусов - отсутствие возможности миграции виртуалки с машины на машину одним движением, но нам это и не надо.

Размещаем на машинах виртуалки и каждой виртуалке прописываем максимальные значения через vzctl set. Это делаем для того, что бы пока нет нагрузки, набрать статистику и исключить проблемы, когда что-то напарывается на барьеры.

Запускаем виртуалки и отдаем над ними контроль тем, кому он нужен.

Пока репозитории репозитарятся, а веб-сайт готовится принять посетителей, занимаемся страшной штукой под названием "disaster recovery". Грубо говоря, что делать, если что-нить навернется.

Методика простая. Так как дисковое пространство на всех серверах больше суммарного объема виртуалок, то тупо пускаем rsync на /vz/private. В результате мы имеем на всех машинах более-менее актуальные копии всех виртуалок. Пока пускаем раз в сутки, но потом когда поймем нагрузку, будем пускать чаще.

Результатом этого станет то, что в случае "взрыва" любого из серверов мы можем поднять "взорванные" виртуалки на любом другом практически сразу же, как обнаружим "взрыв".

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

Ну и в качестве завершающего аккорда запускаем на серверах всякие скрипты, которые рисуют красивые графики загрузки каналов, дисков и прочей фигни.

Запускаем!

Теперь про увеличение нагрузки. По КД мы должны обеспечить ого-го и угу-гу. Веб масштабируется легко. Сайт использует прогрессивные технологии под названием Ruby On Rails, поэтому методики масштабирования сайта отработы не раз и не два и не три.

Для репозитария в части веба масштабирование тоже не является задачей - это по большому счету простой веб-сайт. В части бэк-энда еще проще - тупо добавляем сервера и все.


Вот так оно и работает :)
Tags: школьный проект
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 31 comments