книги хакеры / журнал хакер / 145_Optimized

Удобная кнопка авторизации через «В Контакте»

Совет№9:Серверные компоненты

С самого начала важно понять, что быстродействие Drupal напрямую зависит от настройки компонентов внешней среды. К таковым относятся web-сервер, СУБД и PHP. Если что-то из этого списка работает неэффективно, то ни о какой хорошей производительности не может быть и речи. Настраивать все компоненты можно долго, но я хотел бы обратить твое внимание на самые важные настройки — настройки PHP. Весь Drupal написан сугубо на PHP, поэтому крайне важно позаботиться о настройке этого интерпретатора. В конфигурационном файле PHP есть куча директив, но для Drupal особенно важной будет php_value memory_ limit. Как видно из названия, директива отвечает за объем памяти, выделяемой для выполнения сценария. Понятное дело, что чем ее больше, тем лучше. Если говорить конкретно в цифрах, то крайне желательно установить значение больше 32M (то есть больше 32-х мегабайт). Помимо установки объема памяти, не менее важной опцией является max_excecution_time (максимальное время выполнения сценария). Обычно здесь выставляют значение от 30 и выше. Чем больше будет время исполнения сценария, тем меньше ты будешь видеть белый экран смерти.

• Акселератор для PHP

Как бы в народе не хвалили PHP за простоту и быстродействие, трудно не согласиться с тем, что этот интерпретатор все равно медленный. Для выполнения каждого сценария интерпретатору PHP необходимо сначала считать и разобрать весь код сценария, затем выполнить его и вернуть результаты. Эта операция проводится постоянно, и на нее тратится самый драгоценный ресурс — время. Для решения этой проблемы были придуманы так называемые php-акселераторы — программы, ускоряющие выполнение php-сценариев. Ускорение достигается за счет кэширования байт-кода

Сайт легендарной Убунты построен на Drupal

Совет№12:Drupal.API

Существует заблуждение, что вместо использования API можно отдать предпочтение дедовскому способу — прямому выполнению SQL запросов. Конечно, есть ряд задач, решать которые лучше именно таким способом. Но это скорее исключение. Во всех остальных ситуациях правильнее будет пользоваться Drupal.API. Вызывая документированные функции, разработчик может быть уверен, что его действия не повлекут за собой негативные последствия. К примеру, если для добавления нового пользователя существует специальная функция, то ни в коем случае не стоит показывать понты и делать это запросом. В случаях, когда функции мало, желательно все же сначала посмотреть ее исходник, изучить выполняемые запросы и только затем на их основе составлять собственные.

Совет№13:Нагрузочное тестирование

Вновь созданный проект лучше сразу подвергнуть жесткому тестированию. Хоть трижды закрути все болты и гайки, но шанс, что сайт не выдержит шквала посетителей, есть всегда. Желательно сразу потратить время на нагрузочное тестирование и уже на ранних этапах исключить возможные провалы. Для проведения подобных тестов хорошо себя зарекомендовал сервис http://loadimpact. com. Он предлагает различные тесты для проверки web-проекта на устойчивость к нагрузкам. Тесты есть на любой вкус и кошелек. Для

серьезного анализа имеется pro-версия. Она, конечно, стоит денег, но тестов в ней больше, а значит и польза — ощутимей. Не пугайся: если проект поднимается на общественных началах, то хватит и бесплатного варианта. Во всяком случае, ты будешь точно знать, что твой сайт уверенно себя чувствует при заходе на него пятидесяти человек.

Совет№14:Хорошийиндеец— мертвыйиндеец

Ни для кого не секрет, что олимп web-серверов уже много лет возглавляет Apache. Это действительно хорошее и качественное ПО, хотя и не слишком быстрое. Apache в связке с Drupal показывает не лучшие результаты и при большом наплыве посетителей становится самым узким местом. Частично победить тормоза позволяет хардкорный тюнинг, но превратить его в гепарда все равно не удастся. Лучше сразу от него отказаться и забыть, как о страшном сне. А чем же тогда пользоваться? Конечно же nginx (http://sysoev.ru/nginx)! В настоя-

щее время nginx, пожалуй, самый быстрый web-сервер. Тот же Apache он обходит уже на старте и практически ничем ему не уступает (за исключением количества модулей, которое у nginx пока невелико). Недавно на нашем проекте (http://vr-online.ru) мы решили отказаться от Apache и полностью перешли на nginx. Производительность возросла даже визуально: при открытии страниц создается впечатление, что на генерирование вообще не требуется времени. При использовании Apache об этом можно было только мечтать.

Совет№15:Приручаемnginx

Nginx превосходно подходит для Drupal'овских проектов, но чтобы все четко и правильно работало, нужно уделить время настройке. Тут методом научного тыка не обойтись. Придется пересилить себя и про- читать объемную документацию, а также повторить все полученные знания на практике. Чтобы как-то облегчить себе жизнь, рекомендую скачать конфиг (https://github.com/yhager/nginx_drupal) для nginx, специально созданный для Drupal. Предложенный конфигурационный файл содержит все необходимое для того чтобы Drupal корректно заработал с nginx. Если перечислить возможности, которые отражены в конфигурационном файле, то получится:

•чистые url;

•мультисайтинг;

•повышенное время выполнения fastcgi;

•поддержка boost и так далее.

Совет№16: ГотовьсякDrupal7

Не забывай, что разработчики уже давненько трудятся над созданием седьмой версии этого замечательного фреймворка. Совсем недавно вышел первый (на момент написания этих строк) релиз-кандидат, и я бы рекомендовал тебе его потестировать при возможности. В новой ветке реализованы интересные фичи, которых так давно не хватало Drupal'у.

Заключение

Drupal — не самая простая CMS, которую легко настроить в несколько кликов мышкой. Чтобы выжать из него максимум и поднять нетипич- ный проект, придется повозиться. Точнее — как следует повозиться.

Однако после первого успешного проекта Drupal уже не будет казаться таким страшным и странным. Не отступай и не сдавайся! Пробуй, экспериментируй и, я надеюсь, мои drupal'ные советы тебе помогут. Удачи! z

Мы привыкли к тому, что все наши приложения, сетевые сервисы и базы данных работают на реальных, осязаемых машинах, которые необходимо покупать, доставлять, выделять площадь для установки, настраивать и следить за работоспособностью. Однако времена меняются и на смену дорогостоящим железным серверам приходят серверы виртуальные, которые гораздо дешевле, удобнее в обслуживании и совершенно не боятся экспериментов и чрезвычайных ситуаций. Спустя несколько секунд после клика по кнопке «купить» наш новенький сервер готов к работе и мы даже не подозреваем о том, как он функционирует, какую часть серверной занимает и сколько выделяет тепла. А также не заботимся о своевременной замене жестких дисков и других компонентов системы. Все это происходит где-то далеко в облаке, скрыто от наших глаз. Виртуальные серверы получили очень широкое распространение после открытия сервиса Amazon EC2, который стал эталоном для облачных сервисов уровня IaaS (это когда в аренду сдается целая инфраструктура для управления виртуальными серверами, а не

выделенная виртуальная машина или приложение). EC2 позволил организациям отказаться от собственных серверных и половины штата системных администраторов в пользу парка удобных в сопровождении удаленных серверов, которые можно использовать для любых нужд, увеличивая количество машин по мере надобности. Сервис, созданный Amazon, оказался не только удобным в использовании, но и весьма технологичным, так что многие, кто пытался создать облако для своих нужд или конкуренции с Amazon, терпели неудачу. При всей простоте самой идеи, облачный сервис уровня IaaS очень труден в реализации, потому как требует создания умной, самоконтроллируемой инфраструктуры, которая бы умела равномерно распределять нагрузку между физическими машинами, не боялась расширения и была устойчива к сбоям оборудования. Такое было под силу только большим коммерческим организациям, которые просили за свои продукты немалых денег, а тем, кто не мог их заплатить, приходилось довольствоваться тем, что есть: большим количеством разрозненных компонентов, которые нужно собирать вместе и долго тестировать надежность работы получившейся системы.

Eucalyptus стал одним из первых Open Source проектов, нацеленных на создание комплексной инфраструктуры, позволяющей поднять cloud-сервис уровня IaaS не прибегая к дополнительным инструментам. Предлагаемая им инфраструктура действительно удобна, эффективна, устойчива и, что немаловажно, полностью совместима с клиентскими инструментами Amazon EC2. Тем не менее, инфраструктура на основе Eucalyptus оказалась недостаточно масштабируемой, а публичная версия фреймворка сильно

урезанной по функциональности. Поэтому совсем скоро на рынке появился проект, призванный решить эти проблемы и, ни много ни мало, стать стандартной открытой платформой.

OpenStack был образован путем слияния двух независимых проектов: «Cloud Files and Cloud Servers», разрабатываемой RockSpace, и «Nebula Cloud Platform», созданной NASA. В результате получилась довольно интересная солянка, разделенная опять же на два почти независимых продукта: OpenStack Nova и OpenStack Swift.

Nova—счетнаямашина

Главный компонент OpenStack — это Nova (Compute), контроллер, управляющий работой виртуальных машин. Фактически Nova отвечает за все: обрабатывает запросы на создание виртуальных машин, соединяет их с внешним миром, следит за работоспособностью и распределением нагрузки на физические машины и каналы связи, реагирует на сбои и т.д. Nova основана на коде системы NASA Nebula (http://nebula.nasa.gov/), написана на языке программирования Python и опирается на протокол обмена сообщениями AMQP. Система состоит из семи обособленных компонентов:

•контроллер облака (Cloud Controller) следит за состоянием системы и выступает в роли связующего звена всех остальных компонентов системы;

•сервер API (API Server) реализует web-интерфейс, позволяющий управлять контроллером облака;

•контроллер вычислений (Compute Controller) отвечает за запуск виртуальных машин и их связь со всей остальной инфраструктурой;

•хранилище (Object Store) предоставляет сервис хранения данных, совместимый с Amazon S3;

•менеджер аутентификации (Auth Manager) предоставляет сервисы аутентификации и авторизации;

•контроллер томов (Volume Controller) позволяет подключать виртуальные устройства хранения к виртуальным машинам;

•сетевой контроллер (Network Controller) создает виртуальные сети, позволяя виртуальным машинам взаимодействовать друг с другом и внешней сетью;

•планировщик (Scheduler) ответственен за выбор подходящего контроллера вычислений для запуска новой виртуальной машины. На рисунке хорошо видно, как эти компоненты связаны между собой. Сервер API, контроллер облака и менеджер аутентификации составляют «управляющий центр» облака, который должен работать на выделенной машине. Администратор использует утилиту nova-manage для управления характеристиками всей инфраструктуры и доступом к ней пользователей. Клиенты, желающие использовать облачный сервис, подключаются к серверу API с помощью

Типыоблачныхсервисов

клиентских утилит Amazon EC2 или их свободного варианта под названием euca2ool из проекта Eucalyptus. Еще одна выделенная машина отвечает за управление хранилищем данных (Object Store). В состав Nova вклю- чена только начальная реализация S3-совместимого хранилища данных, которая может быть использована только для отладки. В реальных же проектах на ее месте должен быть установлен Swift, развивающийся обособленно от Nova.

Еще одна машина — это контроллер томов, позволяющий подключать к виртуальным машинам своего рода внешние накопители данных (виртуальные флэшбрелки). Его присутствие в инфраструктуре совсем не обязательно.

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

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

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

Обработка пользовательских запросов в такой системе выглядит следующим образом: используя клиентские инструменты, пользователь инициирует запрос на создание виртуальной машины к серверу API. После аутентификации и авторизации пользователя сервер API разбирает запрос и посылает его контроллеру облака, который инициирует три новых запроса: к сетевому контроллеру, к хранилищу и к планировщику. Сетевой контроллер выделяет IP-адрес для новой виртуальной машины и возвращает его контроллеру облака. В сетевом хранилище происходит поиск подходящего образа жесткого диска для будущей виртуальной машины,

адрес которого возвращается контроллеру облака. Теперь, имея все необходимое для создания новой виртуальной машины, контроллер облака посылает запрос планировщику, который выбирает наиболее подходящий контроллер вычислений и отдает ему запрос на создание ВМ. После того, как новая ВМ будет запущена, контроллер облака завершает свою работу и сообщает серверу API об успехе всей операции. Теперь пользователь может подключиться к ВМ, а всю деятельность по поддержанию ее в работоспособном состоянии, выделении дискового пространства, маршрутизации сетевых пакетов и прочую черную работу берет на себя система.

Стоит заметить, что облачная инфраструктура на основе OpenStack получается очень гибкой и управляемой. Компоненты системы полностью обособлены друг от друга и общаются только с помощью отправки асинхронных сообщений или протокола HTTP. Уже настроенная и работающая система легко выдержит любые изменения в своем дизайне и не потребует много времени на переконфигурирование. Кроме того, OpenStack не замкнут сам в себе и везде, где это возможно, использует сторонние продукты. Для его управления можно использовать стандартные клиенты сервиса Amazon EC2, а для запуска виртуальных машин применять наиболее удобные в данном конкретном случае системы виртуализации (на сегодня поддерживаются KVM, UML, XEN, HyperV и qemu).

Swift—безграничное хранилище

Swift (OpenStack Object Storage) — это полностью распределенное, отказоустойчивое высоконадежное хранилище данных, созданное по образу и подобию Amazon S3. Swift почти полностью основан на наработках компании Rackspace.

Система состоит из четырех основных компонентов:

•прокси-сервер (Proxy Server), объединяющий все остальные компоненты системы вместе;

•объектный сервер (Object Server), ответственный за хранение данных;

•контейнерный сервер (Container Server), ответственный за отдачу списка объектов;

•сервер аккаунтинга (Account Server), отдающий листинги контейнеров для конкретного аккаунта. Типичная Swift-инфраструктура представляет собой кластер, одна из машин которого выполняет функции прокси-сервера, несколько машин работают в качестве контейнерных серверов и серверов аккаунтинга, а все остальные (сотни и тысячи машин) представляют собой контейнерные серверы.

HTTP://WWW

links

•ОписаниеархитектурыNova: http:// nova.openstack.org/ nova.concepts.html;

•Руководство

администратора

Nova: http://nova. openstack.org/ adminguide/index. htmll;

•Руководствопо созданиюNovaкластера: http:// wiki.openstack. org/NovaInstall/ MultipleServer;

•ОписаниеархитектурыSwift: http:// swift.openstack. org/overview_ architecture.html.

info

OpenStack подде-

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

Подготавливаем ядро и рамдиск к загрузке в облако

Прокси-сервер поддерживает внешний ReST-ful API, реализованный в рамках протокола HTTP. Поэтому запрос доступа к объектам внутри хранилища выглядит очень наглядно и просто:

GET http://swift.host.com/v1/account/container/object

Здесь account — это пользовательский аккаунт, container — пространство имен, используемое для классификации данных, а object

— непосредственно данные (или, другими словами, файл). Прокси-сервер использует так называемые кольца (rings) для поиска реального положения данных в кластере. Это своего рода база данных, описывающая то, где на самом деле расположены данные. Она модифицируется при каждой записи новых данных в хранилище, их удаления или выходе узлов из строя. Для аккаунтов, контейнеров и объектов предусмотрены отдельные кольца.

Объектные серверы — наиболее важный компонент Swift-клас- тера. Они отвечают за хранение и отдачу данных. Любые объекты хранилища в конечном счете оседают на жестких дисках этих серверов, которые записывают данные в обычные файлы, сопровождая их метаданными, записываемыми в расширенные атрибуты файлов (xattr).Надежность хранения данных достигается за счет дублирования сразу на несколько серверов, так что если один из них выйдет из строя, система сможет восстановить данные с другого сервера и вновь продублировать их. По умолчанию система создает три копии каждого объекта, так что в качестве железной составляющей кластера можно использовать даже самые дешевые машины, не снабженные RAID-контроллерами. Один из основных плюсов системы состоит в ее прозрачной масштабируемости. Расширить хранилище можно, просто подключив новый узел к кластеру, а всю остальную работу по его синхронизации с хранилищем возьмет на себя Swift. Лучше всего этот кластер подходит для хранения таких данных, как образы виртуальных машин (собственно, для этого он и был создан), банки фотографий, электронные письма, бэкапы и тому подобное.

Пробуем

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

С помощью Nova это довольно просто сделать, и нам даже не понадобится помощь Swift, мы просто установим все компоненты системы на одну машину и посмотрим, как они функционируют вместе. В дальнейшем инфраструктуру можно будет расширить до нескольких машин, добавив к ней распределенное хранилище данных, но это тема для отдельной статьи.

Несмотря на свою молодость, Nova и Swift уже успели попасть в официальные репозитории некоторых дистрибутивов, поэтому для установки нужных нам компонентов можно использовать стандартный менеджер пакетов:

Архитектура Nova

$ sudo apt-get install rabbitmq-server \ redis-server

$ sudo apt-get install nova-api \ nova-objectstore nova-compute \ nova-scheduler nova-network \ euca2ools unzip

Фактически уже после установки система полностью готова к работе, остается только завести учетную запись суперпользователя:

$ sudo nova-manage user admin vasya

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

$ sudo nova-manage project create \ experiments vasya

Далее просим систему запаковать данные, необходимые для доступа к проекту, в zip-архив:

$ sudo nova-manage project zipfile \ experiments vasya

Теперь эти данные можно использовать, чтобы управлять работой облака с помощью EC2-совместимых инструментов. Для этого распакуем архив и выполним команды, прописанные в файле novarc:

Добавляем нового пользователя и создаем проект

$ unzip nova.zip $ . novarc

Чтобыпротестироватьработусервиса,нампонадобитсяEC2-образ виртуальноймашины.

МинимальныйLinux-образможнополучитьнасайтеRackspace:

$ wget http://c2477062.cdn.cloudfiles.rackspacecloud. com/images.tgz

Распаковываем:

$ tar -xzf images.tgz

Образнеобходимозарегистрироватьвоблаке,поэтомуделаем следующее:

1.Создаемманифестыдляядраирамдиска:

$ euca-bundle-image -i images/aki-lucid/image \ -p kernel --kernel true

$ euca-bundle-image -i images/ari-lucid/image \ -p ramdisk --ramdisk true

2.Заливаемядроирамдисквоблако:

$ euca-upload-bundle -m /tmp/kernel.manifest.xml -b mybucket

$ euca-upload-bundle -m /tmp/ramdisk.manifest.xml -b mybucket

3.Регистрируемядроирамдиск:

$ euca-register mybucket/kernel.manifest.xml $ euca-register mybucket/ramdisk.manifest.xml

Этикомандыдолжнывыдатьнаэкранидентификаторыядраирамдискавнутриоблака.Ихнужнозапомнитьилископировать.

4.Подготавливаемобразмашины,используязарегистрированныев прошломшагеядроирамдиск:

$ euca-bundle-image -i images/ami-tiny/image -p machine \

--kernel ID-ядра --ramdisk ID-диска

5.Загружаемобразмашинывоблако:

$ euca-upload-bundle -m /tmp/machine.manifest.xml -b mybucket

6.Регистрируемобразмашиныизапоминаемееидентификатор:

$ euca-register mybucket/machine.manifest.xml

Теперьможнозапуститьвиртуальнуюмашинунаисполнение,носна- чаламыдолжныполучитьSSH-ключдлядоступакнашиммашинам:

$ euca-add-keypair mykey > mykey.priv $ chmod 600 mykey.priv

Запускаемвиртуальнуюмашину:

$ euca-run-instances ID-машины --kernel ID-ядра \ --ramdisk ID-рамдиска -k mykey

Смотримсостояниемашины:

$ euca-describe-instances

Проверяем, была ли она корректно запущена: $ virsh list

Подключаемся к машине по SSH:

$ euca-authorize -P tcp -p 22 default $ ssh -i mykey.priv root@10.0.0.3

Убиваем машину:

$ uca-terminate-instances ID-машины

Заключение

Описанноевстатье—тольковершинаайсбергаподназванием OpenStack.Чтобыописатьсистемуполностью,понадобиласьбыцелая книгаиогромноеколичествосвободноговремени.Ноянадеюсь,что иэтанебольшаяпорцияинформациипоможеттебеначатьосвоениеэтого,безсомнения,грандиозногопродукта,которыйвскором временивполнеможетстатьстандартомвсредеоткрытыхоблачных сервисов.z