http://dev.1c-bitrix.ru/community/blogs/alexander_serbul/ В компании я курирую направление контроля качества и внедрений. Моя цель - эффективно постоянно побеждать нестандартные задачи, находить простые и элегантные решения, консультировать в выборе архитектуры, оптимальном проектировании и успешном внедрении решений на базе платформы 1С-Битрикс. Ведь любое внедрение, любой более менее сложный проект подобен ребенку, который начинает жить своей уникально жизнью и должен радовать нас долгие годы! ru http://backend.userland.com/rss2 Sun, 05 Apr 2026 16:27:59 +0300

Сегодня поговорим о том, как наиболее эффективно распределить файлы веб-проекта между нодами веб-кластера. Постараемся определить оптимальную стратегию использования балансировщика. Разложим по полочкам популярные инструменты синхронизации контента, в частности csync2.


Из чего состоит веб-проект на платформе 1С-Битрикс?

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

В файлах хранится информация следующих типов:


1) "Узлы и агрегаты платформы 1С-Битрикс"

Библиотеки, скрипты, вспомогательные файлы: меню, права доступа, свойства разделов и страниц, шаблоны сайтов, файлы конфигурации. Часть файлов находится условно "под капотом", менять их нельзя, они обновляются по технологии SiteUpdate - благодаря чему ядро системы постоянно улучшается, в нем появляется новый функционал.

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


2) Загружаемый контент

Загружаемые в объекты модулей системы (например, "Медиабиблиотеку" ) файлы, документы и изображения хранятся в подпапках системной папки "/upload". Почему файлы и документы хранятся в файловой системе, а не в базе данных? Это общепринятая архитектурная практика, доказавшая свою эффективность: в базе данных хранится справочная мета-информация, которая оптимально проиндексирована для поиска, а сами большие объекты хранятся отдельно (в файловой системе или "облачном" хранилище) и отдаются клиентам напрямую специализированными инструментами, например через nginx.


3) Страницы веб-сайта

Страницы веб-сайта редактируются через административный интерфейс и хранятся в виде файлов. Разделы это папки, страницы - файлы. Размещенные на страницах изображения также можно хранить в виде файлов, например в папке "/images".




====quote====
Нередко в командах разработчиков возникает вопрос - а почему бы не хранить вспомогательные файлы ядра или страницы веб-сайта в базе данных. Все дело в производительности! Использование простой логики работы с файловой системой часто более предпочтительно, чем двухуровневая конструкция: БД + кэширование. Поэтому информация о меню/права доступа/свойства страниц и разделов - это служебные ... файлы.

Также нередко спрашивают, а почему бы не использовать для файлов конфигурации популярные форматы XML, YAML,  а для файлов шаблонов компонентов вместо PHP скриптов использовать популярный шаблонизатор Smarty (якобы это позволяет эффективно разделить работу верстальщика от работы программиста). Ответ все тот же - профилирование платформы на высоких нагрузках показало, что наиболее предпочтительный формат данных файлов - скрипт php. Разумеется, при необходимости вы всегда сможете использовать любой модный формат файлов в вашем веб-проекте.

=============


Повышение эффективности работы с файлами - на одной ноде кластера

Чтобы максимально разгрузить сервер приложений (его роль часто выполняет Apache, популярность набирает технология php fpm), выполняющий код нашего веб-проекта, работу со статическими файлами переводят на обратный прокси-сервер, например nginx.

Обратный прокси очень эффективно напрямую работает со статическими файлами, в том числе из системной папки "/upload" - изображениями, документами, архивами и т.п., позволяя серверу приложений сосредоточиться на выполнении кода.

Чтобы снизить нагрузку на дисковую подсистему сервера, на linux, например, стараются освободить как можно больше оперативной памяти. В этом случае файлы закэшируются в оперативной памяти и будут отдаваться оттуда значительно быстрее. Особенно это эффективно при интенсивном скачивании клиентами файлов веб-проекта (документы, видео). Поэтому, если известно, что контента ожидается на 10G - устанавливайте соответственно большее количество оперативной памяти.



На графике видим, что на сервере 7.5GB памяти, при этом приложения используют 300МB (nginx+apache), а для кэша и буфферов файловой системы задействовано более 5GB. Этот объем будет отдаваться клиентам значительно быстрее, чем если бы он отдавался напрямую с диска.

Сервер "статики"

Если веб-проекту требуется отдавать значительно большие объемы контента, то можно делегировать задачу отдачи контента серверу "статики". При этом тяжелая "статика" будет отдаваться с отдельного домена/сервера, например images.mysite.ru - что позволит браузерам загружать веб-страницы в параллельном режиме (обходя ограничения браузера на число подключений к одному серверу). Также, на данном домене для "статики" можно сократить до минимума число cookies - сократив трафик и нагрузку на канал.

Для сервера "статики" обычно формируют быструю дисковую подсистему - например рейд10 (или рейд0 - если данные можно перезалить).

Чтобы сохранять "тяжелые" файлы для скачивания на сервере статики, можно организовать для этого отдельный бизнес-процесс: контенщик по ftp сохраняет там файл и вставляет ссылку на него в контент страницы. Можно вместо ftp подмонтировать папку с файлами с сервера "статики" к ноде кластера и тогда нужно будет просто класть файлы в эту папку - главное сформировать правильную ссылку.


Кэширование на обратном прокси-сервере

Популярный nginx поддерживает кэширование статических файлов (или их "перетаскивание"). В этом случае можно не загружать на сервер "статики" файлы по ftp/cifs/nfs - а сделать закачку "автоматической".


Когда нужен CDN

Если ваша задача раздавать тяжелое видео и ожидается большое число одновременных скачиваний - наверно лучшим решением будет CDN, в том числе облачный.



Промежуточный итог - "тяжелые" скачиваемые файлы желательно хранить отдельно и отдавать оттуда же

На летней партнерской конференции 2011 мы расскажем, какие новейшие технологии в данной области мы включим в платформу 1С-Битрикс. Приходите, не пожалеете!  


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


NFS/CIFS

Казалось бы все просто. Экспортируем папку с файлами проекта на другие ноды веб-кластера по NFS/CIFS. Проблема один - производительность. К сожалению, при высоких нагрузках веб-проект будет работать значительно медленнее на нодах, подсоединяющихся к реальному диску "через сеть". Проблема два - при выходе из строя ноды1, остальные ноды ... потеряют данные и не смогут работать.


OCFS2(GFS2)

Эти и другие кластерные системы предназначены для работы с разделяемыми дисками. Например диск C должен быть примонтирован как на ноду1, так и ноду2. Это конечно эффективно, но требуются дополнительные затраты на оборудование. Передовые облачные хостинги, такие как Amazon или Оверсан-Скалакси, пока не предоставляют такую услугу.


OCFS2(GFS2)  over DRBD

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


Csync2

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


Конфигурация

В системе может быть сколько угодно файлов конфигурации csync2. В этом случае создается такое-же количество баз данных SQLite, используемых для хранения информации о файлах. Это пригодится, когда файлов много и хранение их в одной базе отрицательно сказывается на производительности.
Сервер утилиты при этом работает на одном порту и разбирает с какими конфигами работать в зависимости от режима работы клиента.


Начальный импорт данных

Если вы не можете остановить основной сервер с файлами при настройке синхронизации файлов на вторую ноду веб-кластера, то
можно поступить так:

1) Выполнить индексацию файлов на ноде1: csync2 -cIr /
2) Запустить архивацию файлов на ноде1. Да, мы понимаем, что архив может оказаться нецелостным, но мы сделали "снимок" в п.1
3) Распаковать архив на ноде2.
4) Выполнить индексацию файлов на ноде2: csync2 -cIr /
5) Выполнить первоначальную синхронизацию в обе стороны. На ноде1, затем на ноде2: csync2 -cr /, csync2 -u


Логика работы

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

Собираем изменения: csync2 -cr /

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

Отправляем изменения на другие ноды веб-кластера: csync2 -u. Предварительно можно добавить ключик "холостого" запуска - d.

Проверяем, что изменения ушли из списка модификаций: csync2 -M - он должен быть пустым.


Режим отладки

Если утилита сообщает об ошибке, подробности процесса можно посмотреть, добавив ключики -v или  -vv. Как правило причина ошибки становится понятной.


Производительность

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



Балансировщик

В nginx, например, можно настроить балансировку используя модуль upstream как в режиме round-robin, так и путем хэширования ip-адреса клиента.


Для "быстрого" достижения эффекта он-лайн синхронизации файлов между нодами веб-кластера поможет использование режима ip_hash - каждый клиент будет ходить на "свой" сервер и сразу видеть загруженные им файлы. Правда это уже будет не балансировка, а скорее дистрибуция, но конфигурация будет устойчивой - при выходе из строя одной из нод, запросы автоматически будут обслуживаться другой нодой веб-кластера.

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

Однако, если для вас критично, чтобы любые изменения на одной из нод веб-кластера "мгновенно" появлялись на всех других нодах, смотрите на кластерные файловые системы типа OCFS2/GFS2.

SSL-termination



Если вы защищаете доступ к веб-кластеру с помощью SSL - с точки зрения производительности и простоты администрирования рекомендуется установить сертификаты на балансировщике.


Передача IP-адреса через балансировщик на ноды кластера

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

ИТОГИ

Мы предметно поговорили о стратегиях организации работы с файламивеб-кластера на платформе 1С-Битрикс, научились выбирать балансировщик и режимы его работы для использования в кластере, изучили типы размещения "больших" файлов, CDN, кэширование.
Подробнее...]]> http://dev.1c-bitrix.ru/blog/alexander_serbul/2743.php http://dev.1c-bitrix.ru/blog/alexander_serbul/2743.php Tue, 14 Jun 2011 15:33:00 +0400 говорили об эффективном кэшировании на базе memcached, которое появилось в 10 версии платформы "1C-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ).
Сегодня хочу рассказать о появившейся возможности практически неограниченно увеличить "мощность" базы данных интернет-проекта - путем ее кластеризации.

Все лучшее ... Базе!

Обычно для высоконагруженного сайта, особенно со сложной бизнес-логикой, покупают/арендуют отдельный сервер. Мы же не хотим заставить Клиента ждать 10 минут, пока пройдет его платежная транзакция или выгрузится отчет?

Сервер базы данных, так сказать "сердце" сайта, выбирают и покупают, можно сказать, "с трепетом" - еще бы, тут будут хранится оформленные и оплаченные заказы, лицевые счета, персональные данные Клиентов и прочая критичная для бизнеса информация.

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

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

Для быстрой работы дисковой подсистемы, если позволяет бюджет, мы конечно используем эффективный и надежный RAID-10. Ну или хотя бы, как минимум, RAID-1 - для надежного зеркалирования информации.

Для быстрой работы базы данных нам все чаще требуется распространенная сейчас технология отложенной записи на диск (write back disk cache). Разумеется, зная, что при экстренном выключении питания рейд-контроллер или жесткий диск может потерять закэшированную им информацию (несколько заказов, финансовых транзакций) - мы обязательно покупаем рейд-контроллер с батарейкой.

Ну и конечно мы устанавливаем на наш сервер побольше оперативной памяти. Идеальная ситуация, это когда база данных полностью помещается в оперативную память. Например у магазина база занимает 10 Гигабайт - вот если установить на сервер 15 Гигабайт - приложение будет нам благодарно (иначе будет происходить периодическая загрузка данных базы с диска, что конечно медленнее).

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

И еще раз внимательно просмотрев курс по оптимизации мы наконец запускаем быстрый, надежный и крутой сервер базы данных!

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

Можем ли мы быть теперь уверенными в быстрой и надежной работе базы данных интернет-проекта?

К сожалению, нет. Мы упустили два ключевых риска...


Проблема 1 - Дорогое масштабирование вверх

В наш век информации, когда объемы данных экспоненциально увеличиваются каждый год, мы достаточно быстро (кто через полгода, кто через 1-2 года) упремся в производительность сервера базы данных.
Почему? Ведь мы все тщательно будем кэшировать, мы собрали крутой сервер базы данных, быстрый и с большим объемом оперативной памяти...

Дело в том, что интересной и ценной для принятия бизнес-решений информации - много и ее будет все больше и больше. Вы захотите, к примеру, сохранять пути клиентов по сайту и их хиты на ... полгода для детального анализа отделом маркетинга.

Или вам потребуется открыть и подключить к интернет-сайту десяток-другой филиалов с каталогами и ценами и отдельными остатками. И очень захочется (именно захочется) синхронизировать информацию в каталогах с 1С каждые, к примеру, 5 минут.

И наш крутой и мощный сервер базы данных через определенное время начнет уже неуспевать и спотыкаться за полетом фантазии и креативных идей руководителя интернет-проекта.

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

Я нередко вижу проекты, которым для базы данных уже не хватает 8 ядер и 32G оперативной памяти.

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


Решение проблемы 1 - "Master-Slave репликация"

Master-Slave репликация, доступная в модуле "Веб-кластер" платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить описанную выше проблему вертикального масштабирования сервера базы данных.

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

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

Благодаря тому, что возможность работы с несколькими базами данных была изначально заложена в архитектуру платформы 1С-Битрикс и реализована в кластерных редакциях, вашему проекту открываются новые вершины производительности.

И, на что хочется обратить особое внимание, В КОД РАБОТАЮЩЕГО ПРОЕКТА ПРИ КЛАСТЕРИЗАЦИИ БАЗЫ ДАННЫХ НЕ НУЖНО ВНОСИТЬ ИЗМЕНЕНИЯ! Технологию распределения запросов на серверы базы данных мы взяли на себя, предоставим вам возможность эффективно "дирижировать" нагрузкой через определение весов для каждого дополнительного сервера.

Вам достаточно лишь настроить и подключить к платформе один или несколько стандартных недорогих серверов базы данных, с помощью удобного мастера в течении нескольких минут перенести туда данные и ... наслаждаться увеличенной в N-раз производительностью базы данных!

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




Подключение дополнительного сервера базы данных к сайту занимает несколько минут.




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




Проблема 2 - "Непрерывное" резервное копирование

Итак. Нагрузку на базу данных мы победили и в случае чего - добавим в кластер сервер в течение минут. А как обстоят дела с резервным копированием данных?

Оно выполняется раз в сутки. Иногда этого недостаточно.

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

Есть достаточно сложные решения, как "пережить" выход из строя сервера базы данных, типа DRBD репликации, кластерных файловых систем OCFS2, GFS2... но мы рассмотрим наиболее простое, распространенное и надежное решение - да, да, снова репликацию.


Решение проблемы 2 - "Master-Slave репликация"

Master-Slave репликация, доступная в модуле "Веб-кластер" платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить задачу "непрерывного" резервного копирования и высокой доступности базы данных.

При репликации, данные с главного сервера базы данных в онлайне передаются на дополнительные (SLAVE) сервера - т.е. вы имеете копию данных = онлайн бэкап в нескольких экземплярах.

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




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



Выводы

Мы рассмотрели основные задачи, которые необходимо решить для организации высокопроизводительной и отказоустойчивой конфигурации базы данных, и увидели, как они просто решаются модулем "Веб-кластер"  в 10 версии платформы "1C-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ).

В следующей статье поговорим о создании высокопроизводительного кластера серверов приложений - такая задача нередко возникает при создании высоконагруженных интернет-проектов на платформе 1С-Битрикс.
Подробнее...]]> http://dev.1c-bitrix.ru/blog/alexander_serbul/2705.php http://dev.1c-bitrix.ru/blog/alexander_serbul/2705.php Mon, 30 May 2011 12:31:58 +0400
Для чего используется технология кеширования в платформе 1С-Битрикс

Веб-сайт содержит информацию, которая хранится в надежном хранилище: базе данных. В принципе, можно "ходить" за информацией в базу данных постоянно, при каждом обращении к веб-сайту. И такие веб-сайты существуют в природе

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

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

Именно поэтому при разработке веб-сайта мы рекомендуем как можно раньше начать пользоваться преимуществами технологии кэширования, реализованными в платформе 1С-Битрикс.

Технология работает так:

1) Веб-сайт для получения необходимой информации обращается к базе данных и сохраняет ответ (например получаем список новостей).
2) В следующий раз, если информация не поменялась*, веб-сайт не обращается к базе данных, а отдает клиенту сохраненный ответ.
3) Однако, если информация поменялась, веб-сайт снова обращается к базе данных.

*) Технология, которая проверяет, обновилась информация в или нет, называется технологией управляемого кэширования (Сache Dependencies).

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

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

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



"Быстрокэширование" - известная ловушка

Иногда во время разработки активно используются технологии кэширования, однако при возрастании нагрузки база данных подвергается перегрузкам. Почему? Для предупреждения данного риска необходимо сначала обеспечить наиболее оптимальную работу с базой данных С ВЫКЛЮЧЕННЫМ КЭШИРОВАНИЕМ, прежде чем его включать (рекомендую менеджерам интернет-проектов взять это на заметку и включить в чеклист контроля качества проекта).
Типичный кейс данной "ловушки" такой - при включенном кэшировании кастомизированное меню использует 0 SQL-запросов, при выключенном - 5000!


Эффективное кэширование

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

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

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

Решение есть - перенести кэш в memcached. Сервер memcached устанавливается системным администратором за считанные минуты и на веб-сайте нужно установить всего лишь одну настройку платформы 1С-Битрикс.

При использовании memcached временные данные будут храниться в оперативной памяти. Можно выделить для хранения кэша недорогой сервер с несколькими гигабайтами памяти.

При этом, устаревшие данные будут автоматически вытесняться и наш кэш перестанет "расползаться" по системе, пожирая все больше и больше места. Допустим, мы выделили в memcached 4GB места для кэширования и можем быть уверенными, что больше 4GB кэш не вырастет, а наименее часто используемые данные будут вытесняться (алгоритм LRU). Очень удобно и эффективно.


Кластеризованный кэш на базе memcached

Для увеличения производительности и отказоустойчивости проекта, мы переходим на редакцию продукта "Веб-кластер" (или "Бизнес веб-кластер" ). Теперь веб-сайт размещен на двух серверах.

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

Для решения этой задачи - используем кластеризованный кэш серверов memcached ("Рабочий стол/Настройки/Веб-кластер/Memcached" ). Мы подключаем к проекту столько кэширующих серверов, сколько нам нужно - никаких ограничений.



Если подключаемые к кластеру memcached сервера разной мощности или с разным объемом оперативной памяти - желательно соответственно настроить коэффициент их использования через настройку параметра "Процент распределения нагрузки (0..100)" (1).




При настройке подсистемы кластерного кэширования обращаем внимание на параметр:

get_hits: #count# (#hitrate#%)

#hitrate# - показывает эффективность кэширования (3) и должен быть как можно ближе к 100%. Экспериментально регулируем эффективность, постепенно увеличивая объем памяти (2), выделяемой серверу memcached (limit_maxbytes). Рекомендую начинать с объема памяти в 128MB и увеличивать с шагом в 32MB, пока #hitrate# перестанет заметно увеличиваться.

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

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

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

Итоги

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

2) Если вовремя не внедрить в веб-проект технологии кэширования, то скорее всего этим придется заниматься в самое неожиданное время (выходные, летние отпуска) из-за перегрузки базы данных.

3) Мы рассмотрели, как наиболее эффективно использовать технологии кластеризованного кэширования в memcached для повышения отказоустойчивости и производительности веб-проектов на платформе 1С-Битрикс (редакции "Веб-кластер", "Бизнес веб-кластер" ).
Подробнее...]]> http://dev.1c-bitrix.ru/blog/alexander_serbul/2694.php http://dev.1c-bitrix.ru/blog/alexander_serbul/2694.php Mon, 23 May 2011 11:17:45 +0400
Я думаю, публикуемая информация будет интересна прежде всего внедренцам и IT-менеджерам среднего и высшего звена, ориентированным на достижение адекватного результата максимально коротким путем. Многие вещи, убежден, будут интересны системным аналитикам, архитекторам, тимлидам и системным администраторам. Оторванного от реальности технического философствования, холиваров, интеллектуальных рассусоливаний на тему "ООП или на функциях" - не будет, предупреждаю сразу


Итак. Много чего интересного происходит в нашей компании каждый день. Разбираемся и внедряем в продуктах самые новые, самые эффективные технологии. А особенно приятно видеть, как воплощенные в продукты технологии приносят пользу Клиентам, РЕШАЯ возникающие задачи. Абсолютно честно - видеть работающее решение приносит инженеру огромное удовольствие!

Поэтому просто не могу не писать! Горю желанием поделиться с Вами, коллеги, тем, что произвело на меня большое впечатление.

Сегодня хочу рассказать о появившейся поддержке кластеризации в платформе "1С-Битрикс: Управление сайтом 10.0" и вышедшем вчера, в День Космонавтики, "1С-Битрикс: Корпоративный портал 10.0".


"Кластер" (англ. "cluster" ) - это, простыми словами, группа компьютеров, сформированная:

• Для увеличения производительности. Как в хоре - чем больше голосов, тем громче звучит мелодия. Такая группа называется HP-кластер (high performance).
  
• Для увеличения надежности. Один компьютер сгорает, остальные - работают. Т.к. снаружи мы работаем с группой, как одним целым, мы поломку компьютера не замечаем, или замечаем некое ухудшение производительности. Такая группа называется HA-кластер (high availability).
  

Интернет-проекту нужна производительность (HP-кластер)

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

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

• С виртуального хостинга переехали на выделенных сервер.
  
• Долго тюнили производительность этого сервера.
  
• Дисковая подсистема сервера сделала максимально быстрой. С SATA-дисков переехали на SAS-диски. С рейда1 переехали на рейд10 на нескольких дисках. Аппаратный контроллер рейда выбран разумно - он имеет неплохой кэш и батарейку для поддержки кэша с отложенной записью (что значительно ускоряет запись на диск).
  
• Процессоров на серверах аж по 8. Оперативной памяти тоже много, допустим по 16GB.
  
• Сделали отдельный сервер для отдачи статических файлов с производительной дисковой подсистемой.
  

С масштабированием базы данных все немного сложнее, но есть временные решения:

• Базу данных вынесли на отдельный сервер.
  
• Настроили master-slave репликацию и написали код, разделяющий запросы за запись и чтение. Возможно, настроили MySQL Proxy. Но, т.к. платформа не поддерживала до 10 версии использование более одной базы данных, приходилось для этого модифицировать ядро и выполнять глубокую кастомизацию.
  

Но посещаемость интернет-проекта растет так быстро и интенсивность работы Посетителей с данными настолько интенсивна, что ... нужно что-то срочно делать дальше! Нужно повышать производительность!




Интернет-проекту нужна высокая доступность (HA-кластер)

Наверно все, имеющие на хостинге хоть один важный интернет-проект, при пятиминутной недоступности которого звонят телефоны и начинаются финансовые потери с далеким репутационным резонансом, сразу влюбятся в HA-кластер и захотят его использовать как можно скорее. Действительно, но кому не нужна высокая доступность?


К сожалению, страдающих паранойей прошу не читать три следующих раздела.



Розовые очки 1 - "Недорогой сервер своими руками"

Бывает так, что для интернет-проекта купили недорогой новый сервер, сделали на нем рейд1 (или 10), развернули систему, отвезли в дата-центр и запустились.

К сожалению, не подумали о том, что в сервере может "сломаться" не только жесткий диск, а ... блок питания или вентилятор (интересно, для чего в дорогих серверах их резервируют? ). И это событие внезапно произошло. На поиск аналогичного блока питания и замену потрачен - день и проект был недоступен все это время. Репутация интернет-проекта - "подмочена".


Розовые очки 2  - "Дорогой надежный сервер"

Для интернет-проекта купили дорогой, "фирменный" сервер, в котором все, что можно, зарезервировано. Проект запустили. Все спокойно, несколько месяцев. Вдруг сгорает рейд-контроллер. Пока искали аналогичный с похожей прошивкой, интернет-проект был недоступен два дня.  


Розовые очки 3 - "Экскаватор"

К сожалению, рядом с дата-центром проводили строительные работы и ... повредили силовые кабели (нередко происходят аварии на силовых подстанциях). Интернет-проект был недоступен полдня.


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


Возможные решения

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


В отношении облачных хостингов часть этих задач решают хостеры, но есть особенности, которые мы разберем в ближайших постах.

Из множества возможных решений постараемся отобрать самые простые и эффективные.


Проактивный мониторинг!

Но прежде всего, и об этом нужно было написать в начале поста, необходимо обеспечить мониторинг работы интернет-проекта. Как мы узнаем, что интернет-проект "завис"? Когда начнут звонить/писать Пользователи сайта?

Обязательно, прежде всяких экспериментов с кластеризацией/надежностью/производительностью, настроим мониторинг интернет-проекта. Самое простое, с чего можно начать, это установить monit или, посложнее, nagios (zabbix и др.) и проверять каждые 5 минут, что главная страница интернет-проекта загружается без ошибок. Для проекта на платформе 1С-Битрикс также мониторингом проверяем, чтобы на главной странице интернет-проекта не выводилось сообщение "DB query error", говорящее о возможных проблемах с сервером базы данных (проверяем с помощью поиска подстроки или регулярного выражения). Более правильно - мониторить отдельные сервисы.

Настоятельно рекомендую запустить машину низкой/средней производительности для мониторинга на надежном оборудовании и отдельно () от основных серверов. Оповещения обычно настраивают на e-mail и/или SMS. Цель - как только случился инцидент, узнать об этом раньше Пользователей и оперативно отреагировать.




Рецепт 1 - "Горячий" резерв

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

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

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



Рецепт 2 - Активный "горячий" резерв

Очень хочется как-то задействовать вычислительные возможности "горячего" резерва. В самом деле - стоит рядом машина, которая "возможно будет работать когда-то". В принципе, можно организовать выполнение на нем php-скриптов интернет-проекта. Однако, для этого нужно добавить в конфигурацию третий элемент - координатор/балансировщик, который получает запросы Пользователей и направляет их на работающий сервер/распределяет запросы. Добавляя новый узел и усложняя этим систему, не забываем подключить его к системе мониторинга.



Готовое решение под ключ - поддержка технологий кластеризации в "1С-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ) и "1С-Битрикс: Корпоративный портал" (редакция "Холдинг" )

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

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

• Поддержка распределения файлов интернет-проекта на несколько серверов для повышения производительности и отказоустойчивости веб-кластера. Для этого рекомендуем использовать простой и надежный инструмент асинхронной кластерной синхронизации - csync2.
  
• Полная поддержка master-slave (MySQL) репликации на уровне ядра платформы, включая встроенный и настраиваемый SQL-балансировщик. Что особенно важно - не потребуется модифицировать код ранее созданных проектов! Просто добавляем новый сервер БД и производительность работы интернет-проекта с базой данных значительно возрастает.
  
• Добавлять серверов БД в интернет-проект можно теперь столько, сколько нужно, практически без ограничений (узким местом когда-нибудь станет master-сервер, используемый для записи, но для этого нужно очень постараться).
  
• Благодаря технологии "вертикального шардинга" стало возможным вынести отдельные части базы данных (модули) в отдельные базы данных. Если честно, это очень круто - и это стало возможным именно благодаря сбалансированной и модульной архитектуре платформы. Теперь можете выносить активно используемые модули "Поиск" и "Веб-аналитика" в отдельные базы данных.
  
• Для эффективного централизованного хранения кэшей интернет-проекта реализована поддержка отказоустойчивого и высокопроизводительного кластера memcached-серверов. В ближайших постах я подробно остановлюсь на теме кластерного кэширования.
  
• Особо хочу отметить встроенный инструмент нагрузочного тестирования веб-кластера, расположенный в модуле "Монитор производительности". Изюминка в том, что инструмент позволяет измерить и вывести на максимальный уровень фактическую производительность веб-кластера, а не отдельного сервера. До этого, необходимо было использовать для решения подобной задачи инструменты типа jmeter, apachetop и т.п.
  

Процедура развертывания веб-кластера подробно описана в руководстве. Для ознакомления с возможностями веб-кластера рекомендую посмотреть презентацию.

В следующих постах постараюсь более детально рассмотреть особенности вышеуказанных технологий кластеризации, на конкретных примерах рассмотреть кейсы их использования.
Подробнее...]]> http://dev.1c-bitrix.ru/blog/alexander_serbul/2601.php http://dev.1c-bitrix.ru/blog/alexander_serbul/2601.php Tue, 19 Apr 2011 15:04:37 +0400 Меня зовут Александр Сербул. В компании "1С-Битрикс" я курирую направление контроля качества интеграции и внедрений.


Вступление

Успешно выполненный Проект - это всегда победа: удалось решить задачи Клиента, Клиент доволен, позитив и хочется жить дальше! Не всегда удается победить, и тогда нужно мужественно вынести поражение, сделав ПРАВИЛЬНЫЕ выводы. Правильные выводы - это когда дописываешь методики, чеклисты, руководства, чтобы не наступить на грабли ПОВТОРНО. Качественный процесс разработки Проекта - это процесс, использующий весь наработанный, нередко кровью, опыт. Это процесс, который не наступает на грабли.


Кратко о себе

Начинал свое погружение в мир IT разработчиком-любителем на ... известном в СССР компьютере БК-0010-01 . Написав несколько ... игр, вышел за пределы ресурсов в 16кБ ОЗУ и переключился на ZX-Spectrum, затем на PC и началось.

Профессионально разработкой стал заниматься на PHP/Linux в одном из региональных подразделений Сбербанка России. Написал с нуля и до успешного внедрения интранет/интернет решение, настроив мимоходом сервера и ... заскучал

К счастью, встретил отличную команду, партнера 1С-Битрикс, вместе с которой почти 3 года трудился в проектировании и разработке нескольких крупных проектов рунета на платформе 1С-Битрикс.  

Следующие два года возглавлял крупный распределенный отдел веб-разработки в Softline. Благодаря системному подходу и успешному внедрению в производство платформы 1С-Битрикс был построен отличный технологический процесс в стиле RUP+Scrum. Цели достигались, Клиенты были довольны, хотелось жить дальше

Почти год был IT-директором известного интернет-магазина программного обеспечения - allsoft.ru.

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

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


Краткий итог

Чем больше я работал с платформой 1С-Битрикс, тем больше она мне нравилась за лаконичность, глубокую продуманность, эффективность и технологичность, направленную на РЕШЕНИЕ ЗАДАЧ ПОЛЬЗОВАТЕЛЕЙ. Я практически всегда получал работающее решение, а не "иллюзию решения"! Почти все возникающие задачи я находил... уже решенными в платформе - что давало возможность проявить свой талант и выложиться в разработке нестандартного крутого функционала.

А разве есть большая награда для Разработчика (пишу с большой буквы), чем удовлетворенный решением Пользователь. Который не только активно с удовольствием пользуется решением, но и строит планы по его развитию. И выстраиваются честные, доверительные и профессиональные отношения Разработчика и Пользователя - а решение становится живым!

В общем, я серьезно влюбился в концепцию эффективного решения задач на платформе 1С-Битрикс, и несколько лет работал над обобщением и систематизацией успешных рецептов, методологий, приемов и подходов - ведущих к победе.  

К сожалению, иногда наблюдаю, как задачи по разработке проектов на платформе 1С-Битрикс сторонними командами разработки решаются не очень эффективно: "недожатое" проектирование, небрежная интеграция, поверхностное тестирование, "недокрученные" сервера под нагрузку. И я ВИЖУ, почему это случается и хочется помочь, подсказать, УБЕРЕЧЬ от ошибок! Честно.

А еще я видел, как иногда целые команды увлекаются процессом, саморазвитием и последними технологиями, забывая о цели "решить задачу Клиента" - это ужасно


Задачи в компании

Моя задача в компании - помочь нашим Партнерам и командам разработки Клиентов решать задачи на платформе 1С-Битрикс эффективно = ПРАВИЛЬНО и КАЧЕСТВЕННО. Т.е. - научить всегда побеждать.

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

Расскажу, как задействовать платформу 1С-Битрикс на "полную катушку". Как открыть в первую очередь для себя, а затем и для Клиента технологическую мощь и надежность, стройность архитектуры и удивительную продуманность и полезность каждой детали продукта. И использовать эту мощь для победы.

Проконсультирую по системному анализу, проектированию, выбору и построению архитектуры, подготовке под высокие нагрузки и дальнейшей поддержке решений на базе 1С-Битрикс.

В этом блоге постараюсь рассказывать обо всем самом интересном и эффективном - инструментах платформы 1С-Битрикс, полезных практических кейсах, успешных архитектурах, высоких нагрузках и многом другом.

Мой твиттер: @AlexSerbul
Е-мейл: serbul@1c-bitrix.ru

Анонсирую следующие посты в блог - они будут посвящены технологиям кластеризации, появившимся в 10 версии продуктов 1С-Битрикс.  

Всех обнимаю и надеюсь на интенсивный, открытый и профессиональный диалог.
Подробнее...]]> http://dev.1c-bitrix.ru/blog/alexander_serbul/let-me-introduce-myself.php http://dev.1c-bitrix.ru/blog/alexander_serbul/let-me-introduce-myself.php Mon, 18 Apr 2011 10:30:31 +0400