Сегодня вечером на РИФ стартуют первые ласточки «Оверсан-Скалакси». Завтра с утра к ним присоединится основная часть команды.
Увидеть нас можно будет везде :) Но об этом позже. Сейчас речь пойдет о том, где нас можно будет услышать.
⇒Введение
Когда у вас есть очень много одинаковых машин (кластер веб-серверов, куча терминалов оплаты, зал с публичными компьютерами), возникает вопрос о поддержании всех машин синхронизированными по версиям установленного ПО.
Традиционным решением является настройка репозиториев и регулярное обновление всех машин средствами пакетного менеджера. Не менее традиционным — сборка в одном месте и почти ручное раскладывание по всем машинам новой версии пакета.
Про очевидную ущербность второго способа говорить, думаю, смысла не имеет. С первым тоже не все гладко. Например, если во время массового обновления некоторые машины были недоступны, то при возвращении в бой ПО на них окажется устаревшим, что может негативно сказаться на целостности системы (например, изменения в протоколе общения между машинами без обратной совместимости). Вписывать в автозагрузку автообновление — тоже не вполне хороший вариант, так как можно получить не доконца оттестированный пакет или из-за проблем со связью не обновиться.
Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.
А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (
PDsh,
dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.
В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в
России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.
По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе
SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.
Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.
В этой статье я расскажу вам о сервере службы каталогов
389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол
LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (
тут про cлужбу каталогов, а
тут про протокол LDAP).
Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.
Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)
Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:
- Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
- Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
- Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
- Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
- Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.
Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно
тут).
В продолжение моего
предыдущего поста о настройке GPFS-кластера, как и обещал, перехожу к описанию весьма распространённых ситуаций, с которыми можно столкнуться при работе с GPFS.
После одной из моих последних статьей на хабре
про серверную оптимизацию мне прислали множество вопросов про распределенные файловые системы. И теперь я нашел в себе силы и возможности написать про замечательную кластерную файловую систему
GPFS.
Описание тестовой лаборатории:
- Сервер виртуализации Xen. Dom0 под SLES11
- 3 Xen DomU виртуальных сервера под quorum-ноды с двумя дополнительно проброшенными блочными устройствами
- 2 Xen DomU виртуальных сервера под client-ноды
Тестовый стенд, основанный на технологии Xen, крайне удобен, ибо позволяет на ходу подцеплять/отцеплять диски от виртуалок, добавлять в них память и процессоры.
Здравствуй! Мы приветствуем тебя в сообществе Всероссийского Движения за Эффективность, известного также как компания
«Оверсан-Скалакси».
Наша компания Оверсан-Скалакси это уникальная команда молодых, но крутых IT-энтузиастов, менее всего готовых следовать замшелым стереотипам и объединённых простой философией. Философия Эффективности это основа нашего бизнеса – мы помогаем нашим клиентам зарабатывать на том, что ещё вчера приносило им обидные, но неизбежные убытки. Мы – специалисты по облачному хостингу, сложной прогрессивной технологии, позволяющей компаниям, связанным с интернет-бизнесом оптимизировать расходы на содержание серверных парков и их обслуживание. Что такое хостинг? Это размещение ресурсов, предназначенных для обслуживания посетителей сайтов на специальных компьютерах, называемых серверами. Что такое облачный хостинг? Это решение при котором сайты с высокой, но нелинейной посетительской нагрузкой (например, новостные ресурсы, социальные сети и т.п.) имеют возможность динамично масштабировать количество ресурсов в соответствии с текущей загрузкой.
И на этом достаточно про облачный хостинг, всё равно у нас всё время будет возникать желание рассказывать о нём, и мы будем стараться себя ограничивать. Давай лучше дальше про эффективность. Стремление к эффективности научило нас задавать вопрос “Почему?” тогда, когда нам кажется, что есть возможность решить проблему нетрадиционным способом. Почему нужно делать так, как делают все? Почему бы не попробовать решить проблему с другой стороны? Почему?
Ни для кого не секрет, что офис — не самое лучшее место для неформального общения и активного отдыха. Конечно, было бы интересно наблюдать за перемещающимися на роликах и велосипедах разработчиками и сисадминами, но… В пятницу работа офиса практически встала — все мысли были только о предстоящем велопробеге длиною в ночь. Даже начальники отделов, сами того не замечая, крутили ногами под своими столами невидимые педали таких же невидимых (но таких желанных!) “железных коней”.
Конференции это всегда шумно, многолюдно, но жутко интересно. Особенно, если действо проходит на свежем воздухе, под чистым июльским небом на палубе теплохода, идущего вниз по Волге-матушке. Да, такой была iCamp в этом году. И несмотря на знойную жару, желающих принять участие в не менее горячих обсуждениях меньше не стало. Хотя для нас конференция началась еще на суше, в Нижнем Новгороде…
Сегодня «облачными» вычислениями не удивишь никого: они везде и повсюду. А в условиях мирового финансового кризиса многие крупные компании, изначально не обращающие внимания на «облачные» сервисы и услуги, резко перенаправили свои денежные потоки именно туда, осознав давние ошибки и просчеты. В этой статье я не буду рассказывать Вам все о cloud computing’e — это мы сделаем как-нибудь в другой раз. Наша цель — рассказать об обстановке в мире, т.е. рассмотреть вопросы, по типу «кто есть who» в мире «облачных» вычислений.