Оптимизация инфраструктуры баз данных и виртуальных сред

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

Проект Server Optimization актуален в случаях:

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

Исходные данные: Сервер на Xeon - 2Гб памяти, RAID. ОС - FreeBSD. БУС - Бизнес.

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

После аудита выявлены следующие основные проблемы:
1. На сервер необходимо установить PHP-акселлератор
2. На старнице /price/ большие проблемы у компонента «nvisions:menu.sections» - генерируется запрос к базе который обрабатывается почти минуту – это основная причина долгой загрузки страницы, а также большая нагрузка на сервер.
3. Медленно работает БД (687 запросов на запись в сек – это очень мало) проблема может быть в конфигурации сервера. Необходимо перевести таблицы в InnoDB и сконфигурировать InnoDB
4. Файловая система не очень быстрая, это могут быть аппаратные особенности сервера (например RAID), но в принципе с такой скоростью сайт должен работать неплохо
5. Проблема в шаблоне сайта (присутствует не существующие ссылки(а)) необходимо ее убрать – это занимает много ресурсов.
6. Необходимо настроить двухуровневую архитектуру на сервере (статическое содержимое отдавать через nginx), это значительно уменьшит нагрузку на сервер Apache, стабилизирует расход памяти на нагрузках, следовательно ускорит работу и повысит надежность проекта в целом.

Проанализируем информацию модуля производительности 1С-Битрикс:

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


Явные проблемы с кодом или компонентами на странице /price/index.php
Подозрительно большое время генерации /bitrix/urlrewrite.php – смотрим дальше:

Ага вот он - источник проблем: в шаблоне присутствует ссылка на несуществующую картинку, это генерирует 404 ошибку, и заставляет Apache обрабатывать эту ошибку и генерировать полноценную страницу.

Эта же проблема влияет на все страницы сайта, связанные с проблемным шаблоном:


А вот и проблемные компоненты на странице:


У компонента меню отключено кэширование.
Итог страницы:

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

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


Urlrewrite.php теперь невызывается на каждом хите



Как видим скорость работы увеличилась в 2 раза(!).

Едем дальше:
Устанавливаем eaccelerator . Здесь не описываю как устанавливается акселлератор, т.к. эту информацию, при необходимости, всегда можно найти на просторах Интернета.







Результат после установки eAccelerator: Еще двух кратный прирост производительности.

Едем дальше: Оптимизируем Базу данных (переводим на InnoDB и оптимизируем настройки)


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

UPDATE:
Рекомендации Модуля Производительности .
Прислушаясь рекомендациям модуля отключаем параметр "open_basedir", т.к. сервер выделен только под наш проект, подразумеваем, что безопасность в целом не нарушиться.

Результат:

Результ как говориться, НАЛИЦО

Осталось переписать "кривоватые" компонеты и проект будет летать.

Также установили и настроили nginx как прокси-сервер для Apache. Картинки не привожу, т.к. цифры практически не изменились. Но по субективной оценки страницы стали грузится еще в пару раз быстрее.

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

Вообщем: Модуль Производительности - очень полезный и удобный инструмент отладки работы проекта и сервера. За что спасибо его разработчикам.

P.S. Лично имею небольшой опыт по работе с Linux. С FreeBSD тесно познакомился в-первые. Удивило, то что после установки некоторого ПО конфг.файлы вообще пустые (например MySQL). Порадовала легкость установки ПО из "портов".

", направление "Системы передачи данных".

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

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

Централизация ресурсов и данных демонстрирует вышеописанные преимущества, но есть различные «подводные камни», которые должны иметь в виду организации, планирующие оптимизировать IT-инфраструктуру. Одна из проблем, с которой они столкнутся, это − снижение производительности приложений. Популярность распределенной модели вычислений была в основном обусловлена необходимостью держать IT-ресурсы как можно ближе к пользователям распределенной сети, чтобы обеспечить максимальную производительность. Консолидация серверов в центре изменяет схему распределения ресурсов на прямо противоположную и поэтому производительность многих приложений ухудшается.

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

Глобально, такие решения оптимизации WAN могут сократить расходы организаций несколькими способами:

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

консолидировать инфраструктуру в центре обработки данных. Компании смогут убрать из удаленных офисов значительную часть IT-инфраструктуры (файловые и почтовые серверы, серверы распространения ПО, порталы SharePoint, ленточные накопители и т. п.) без потерь в производительности и управляемости;

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

Что же представляет собой WAN-оптимизация? Решение оптимизации функционирования сетевых приложений использует клиент-серверную архитектуру и сессионный принцип работы сетевых приложений. Основная его задача — оптимизация сессий приложений. По сути, это совокупность устройств для улучшения работы приложений, устанавливаемых в центре и в каждом региональном (локальном) офисе компании. Они пропускают через себя весь трафик, «перехватывая» и оптимизируя рабочие сессии приложений.

Существует некоторое количество производителей, предлагающих решения в области оптимизации передачи трафика по протяженным WAN-каналам. К наиболее известным из них на российском рынке относятся компании Riverbed (с продуктом SteelHead), Cisco (продукт WAAS), Juniper (продукт WXC) и BlueCoat (продукт ProxySG).

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

Все рассматриваемые механизмы оптимизации приложений используют сегментацию сессии, разбивая ее между клиентом и сервером на три сегмента: между устройством оптимизации и рабочей станцией, между устройствами - поверх сети WAN, и между устройством оптимизации и ЦОД (сервером). В первом и третьем сегментах сессия работает поверх ЛВС, и недоработки протокола TCP не влияют на задержку приложений. Второй сегмент оптимизируется средствами регулировки скорости работы TCP. В результате обеспечиваются необходимые минимумы: по задержке при передаче трафика через WAN и по времени отклика приложений. Рассмотрим механизмы, которые в том или ином виде лежат в основе решений каждого из производителей оптимизаторов.

Механизмы компрессии способны ускорить передачу данных за счет повышения информативности передачи информации в единицу времени. Чаще всего, данные, передаваемые по сети, представлены в неоптимальном формате и имеют неоправданно большой объем. Сейчас, при активном использовании в разработке приложений, например, языка XML или других языков представления информации в текстовой форме, нет нужды заботиться о представлении данных. Это повышает скорость и простоту разработки, но одновременно приводит к тому, что по сети передаются, по сути, неструктурированные данные, внося в трафик большие объемы избыточности.

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

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

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

Важным отличием от обычных кэширующих устройств является тот факт, что оптимизаторы разбивают информацию на части/блоки и уже их сохраняют на жесткий диск. Это интересно с той точки зрения, что если мы изменим часть информации в заново передаваемом файле (например, вставим слайд или картинку в документ), то будет передано именно изменение, а не весь файл целиком. Механизмы динамического разбиения передаваемой информации на блоки и отслеживание изменений являются проприетарными и не подлежат разглашению. Если говорить об особенностях работы, то производители используют 2 подхода. Отличительной чертой первого из них является его унифицированность, т.е. при передаче одного файла в разные филиалы в центральном оптимизаторе будет сохранена всего одна копия файла для всех удаленных устройств оптимизации. Во втором случае пространство жесткого диска динамически разбивается пропорционально количеству удаленных офисов (удаленных оптимизаторов), и в случае передачи одного файла всем филиалам аналогичная копия будет отражена в каждом сегменте жесткого диска, «отвечающему» за свой филиал.

Очевидно, что механизм кэширования работает в паре с механизмом компрессии. Именно благодаря этим двум механизмам, производители оптимизаторов показывают красивые графики, где уровень оптимизации может достигать 150-200Х. Нам удавалось получать такие же данные при многократных пересылках одного и того же объемного файла данных, поскольку после первой передачи он сохранялся в кэш устройств и далее передавались лишь килобайты ссылок, указывающих на место файла в жестком диске. Здесь сразу возникает логичный вопрос - каков объем жесткого диска и можно ли к оптимизаторам подключать внешние хранилища? Некоторые производители как-то упоминали о возможности появления такого рода оборудования, (но оно уже будет предназначено исключительно для установки в ЦОД).

Механизмы TCP-оптимизации работают на транспортном уровне. Это основное «поле битвы» производителей оптимизаторов до того, когда они стали «взбираться» на уровни выше (прикладной). Транспортный протокол TCP разработан в 1980 г., и сегодня не претерпел серьезных изменений, тогда как технологии передачи данных серьезно изменились. При потере пакетов стандартный TCP-протокол резко снижает скорость - практически вдвое, и ее увеличение от этого уровня в дальнейшем происходит линейно и небольшими шагами. Поэтому, даже сравнительно небольшой уровень потери пакетов (2-3% потерь считается нормальным), приводит к частым и резким потерям скорости работы сети.

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

Механизмы оптимизации уровня приложений предлагают ускорение работы самих бизнес-приложений через WAN-каналы. Именно реализация некоторых протоколов в популярных продуктах, к сожалению, далека от совершенства. В частности, протокол CIFS (Common Internet File System), активно использующийся в сетях Microsoft, создает избыточный объем служебных сообщений (подтверждение доставки, готовность устройств и т.п.). В локальной сети эти излишки не вносят существенной задержки во время отклика, но в распределенной сети становятся значимыми. Устройства оптимизации умеют обрабатывать большую часть малозначимых сообщений локально, без передачи через WAN, уменьшая объем трафика и сокращая время отклика ряда функций сетевых приложений, таких как сетевая печать, доступ к файловым сервисам, и т.п. Собственно, на сей день как раз в этой области и происходит конкурентная борьба у производителей. К наиболее часто оптимизируемым протоколам следует отнести CIFS, NFS, MAPI, Video, HTTP, SSL и Windows printing. Этот «джентльменский набор» присутствует в портфеле почти любого производителя, а вот оптимизируют их по-разному.

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

Нетрудно догадаться, что все оптимизаторы работают с TCP-based приложениями, а значит остальной трафик проходит сквозь, без оптимизации. То же самое можно сказать и про шифрованный трафик (исключение, пожалуй, составляет SSL - многие оптимизаторы могут «порвать» сессию, произвести оптимизацию трафика, и обратно зашифровать).

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

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

Помимо компаний с распределенной структурой, данное решение может быть интересно и операторам, которые могут предоставлять компаниям услуги по оптимизации (напр., аренда). Такие услуги становятся популярными в Европе.

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

Решение WXC от Juniper отличается тем, что весь трафик упаковывается в UDP-туннель, т.е. оптимизация происходит над всем трафиком. В таком подходе, безусловно, есть свои преимущества. К ним я бы отнес достаточно высокое «среднее по больнице» значение оптимизации над всем трафиком (на основе тестирования у одного крупного заказчика).

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

Резюмируя все вышесказанное, хочется отметить, что WAN-оптимизация - решение интересное, довольно прозрачное для бизнеса, но, к сожалению, пока еще не получившее большой востребованности в российских компаниях. На основе внедрений получалось добиться уменьшения трафика в среднем в 2-3,5 раза и значительно ускорить отклики приложений. К примеру, у одного нашего заказчика, на спутниковых линиях, было сохранено порядка 20 часов откликов при месяце тестирования. А нашей компании внедрение данного решения позволило достигнуть двукратной экономии при оплате сетевого трафика, а также увеличить скорость работы корпоративных приложений в среднем в 1,7 раза. При этом срок возврата инвестиций в проект составил всего 3 месяца.

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