• Производительность mdadm raid 5,6,10 и ZFS zraid, zraid2, ZFS striped mirror

      Тестируем производительность ZFS и mdadm+ext4 на SSD Sandisk CloudSpeed
      для выбора технологии создания локального дискового массива.


      Цель данного тестирования — выяснить, с какой реальной скоростью смогут работать виртуальные машины в raw файловых образах, если разместить их на 4-х производительных SSD-дисках. Тестирование будет производится в 32 потока, чтобы приблизительно создать условия работы реального гипервизора.

      image
      Читать дальше →
    • Virtuozzo Storage: Реальный опыт эксплуатации, советы по оптимизации и решению проблем

      • Tutorial

      Данная статья посвящена реальному опыту эксплуатации кластеров на базе Virtuozzo Storage.
      За год активного внедрения и использования платформы на серверах нашего хостинга, а также при создании кластеров для наших клиентов, у нас собралось достаточно много советов, замечаний и рекомендаций. Если вы задумались о внедрении этой платформы, вы сможете учесть наш опыт при проектировании своего кластера.
      Читать дальше →
    • Производительность Bitrix Старт на Proxmox и Virtuozzo 7 & Virtuozzo Storage


        Тестирование производительности Bitrix Старт на двух принципиально разных платформах. Замерять будем при помощи встроенной панели производительности Bitrix.

        C одной стороны, бесплатная версия Proxmox 4.4, LXC контейнеры с использованием файловой системы ZFS на SSD дисках.

        С другой стороны, лицензионная Virtuozzo 7 CT + Virtuozzo Storage. В этом варианте мы используем обычные SATA диски + SSD для кеша записи и чтения.

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

        По этой причине, полноценно сравнивать две платформы, конечно, не корректно, но, если
        интересно узнать как можно увеличить производительность сайта, используя одно и тоже железо, одинаковую конфигурацию виртуальных машин и ее сервисов, то данная статья может быть вам полезна.
        Читать дальше →
      • Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва оптимизаторов кода» apc vs xcache vs opcache





          В продолжение статьи:

          Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP




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

          Для ранних версий PHP, проведено тестирование между оптимизаторами кода apc, xcache и opcaсhe.
          Эта статья не содержит тестов на производительность, таких как нагрузочные тесты ab и siege. Возможно, об этом я напишу в одной из следующих статей.
          В данном случае, меня не интересует сколько страниц за секунду способна сгенерировать та или иная версия php-интерпретатора, скорее то, с какой скоростью она сгенерирует мне страницу и с какой задержкой.
          В данном случае разница в том, что тесты производительности замеряют отношение скорости интерпретатора к общим ресурсам сервера, а так же подготовленности других связанных компонентов web-системы к работе на повышенных нагрузках.
          Остановимся на скорости и отклике. Очевидно что производительность зависит от скорости, но высокая скорость не может гарантировать высокую производительность. Это, возможно, связанно с тем, что недостаточно хорошо настроен web-сервер или база данных, а также с какими-то не было ограничениями, например сетевого стека.
          Что бы не заниматься попыткой объять необъятное, мы просто замерим скорость и отклик работы интерпретаторов php, на мощном сервере без нагрузки, с одинаковыми конфигурациями web-сервера, базы данных и операционной системы для всех испытуемых. Используем конфигурацию php-fpm + nginx. База данных MariaDB. Все технические детали скрыты под спойлером ниже.

          Читать дальше →
        • Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP



            Эта статья поможет ответить на вопросы владельцев, разработчиков и системных администраторов PHP-сайтов:



            • Как оптимизировать сайт и ускорить его работу?
            • С какой скоростью будет и может работать сайт, в соответствии с теми технологиями на которых он будет запущен?
            • Какие технологии следует использовать настраивая сервер или VPS?


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

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

            И если говорить о серверах для PHP, то такой проблемой является способ исполнения php кода, ровно как и другие значимые настройки окружения на сервере.
            Не зависимо от того, есть ли проблема в вашем коде или её нет, высокая у вас посещаемость или нет, от настроек сервера зависит очень многое. Что бы все сказанное не звучало пустыми словами и была написана эта статья.

            В этом обзоре я протестирую только что установленный сайт на одном из самых распространённых движков управления контентом Drupal 7.33.

            Для теста выбрана лишь одна составляющая php-хостинга. Мы будем тестировать web-серверы Nginx и Apache2, модули mod_php и php-fpm, версии php php53 и php56, посмотрим, как влияют оптимизаторы apc и opcache на скорость работы сайта.

            Читать дальше →
          • «Идеальный» кластер. Часть 2.2: Высокодоступный и масштабируемый web-сервер, лучшие технологии на страже вашего бизнеса

            • Tutorial


            В продолжение цикла статей об «Идеальном» кластере, хочу поделиться рецептами создания надежных, производительных и удобных для управления web-систем.



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

            Кластер, фактически, был построен с нуля. Возникла frontend-backend архитектура. Базы данных отправились в MariaDB Galera, все сайты переехали на унифицированные web-ноды.

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

            Читать дальше →
            • +3
            • 27,1k
            • 2
          • «Идеальный» кластер. Часть 2.1: Виртуальный кластер на hetzner

            • Tutorial


            Хочу отметить, что эта инструкция родилась в процессе проведения экспертизы различных систем виртуализации в стенах компании Acronis.
            Proxmox показал себя с хорошей стороны, возможно наш опыт окажется полезным для решения Ваших задач.


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

            Сейчас я расскажу, как можно быстро сделать из одного сервера целый кластер серверов на базе linux и windows.
            В дальнейших статьях я попытаюсь объяснить, как поднять безопасный web-кластер и использовать все прелести современных технологий виртуализации.
            В этой инструкции речь пойдет о бесплатной системе виртуализации Proxmox, она находится в свободном доступе, но за поддержку требует плату. Мы попробуем обойтись без поддержки и коммерческого репозитория Proxmox. Вот что говорит о об этом продукте википедия

            Proxmox Virtual Environment (Proxmox VE) — система виртуализации с открытым исходным кодом, основанная на Debian GNU/Linux. Разрабатывается австрийской фирмой Proxmox Server Solutions GmbH, спонсируемой Internet Foundation Austria.
            В качестве гипервизоров использует KVM и OpenVZ. Соответственно, способна выполнять любые поддерживаемые KVM ОС (Linux, *BSD, Windows и другие) с минимальными потерями производительности и Linux без потерь.
            Управление виртуальными машинами и администрирование самого сервера производятся через веб-интерфейс либо через стандартный интерфейс командной строки Linux.
            Для создаваемых виртуальных машин доступно множество опций: используемый гипервизор, тип хранилища (файл образа или LVM), тип эмулируемой дисковой подсистемы (IDE, SCSI или VirtIO), тип эмулируемой сетевой карты, количество доступных процессоров и другие.

            Ключевые возможности

            • Простое управление через веб-интерфейс;
            • Мониторинг нагрузки в реальном времени;
            • Библиотека установочных образов (в локальном или удаленном хранилище);
            • Подключение к «физической» консоли гостевых систем непосредственно из браузера (по VNC);
            • Объединение серверов в кластер с возможностью живой миграции виртуальных машин (без остановки гостевой системы);
            • Быстрое развертывание гостевых систем из шаблонов (доступно только для OpenVZ);
            • Автоматическое резервное копирование виртуальных машин.


            Читать дальше →
          • «Идеальный» www кластер. Часть 1. Frontend: NGINX + Keepalived (vrrp) на CentOS



              Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
              Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
              Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

              Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

              На frontend мы будем использоваться связку из двух службы:



              keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

              Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
              Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
              Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места


              nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

              Основная функциональность HTTP-сервера

              • Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
              • Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
              • Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
              • Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
              • Поддержка SSL и расширения TLS SNI.


              Другие возможности HTTP-сервера

              • Виртуальные серверы, определяемые по IP-адресу и имени;
              • Поддержка keep-alive и pipelined соединений;
              • Гибкость конфигурации;
              • Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
              • Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
              • Специальные страницы для ошибок 3xx-5xx;
              • rewrite-модуль: изменение URI с помощью регулярных выражений;
              • Выполнение разных функций в зависимости от адреса клиента;
              • Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
              • Проверка HTTP referer;
              • Методы PUT, DELETE, MKCOL, COPY и MOVE;
              • FLV и MP4 стриминг;
              • Ограничение скорости отдачи ответов;
              • Ограничение числа одновременных соединений и запросов с одного адреса;
              • Встроенный Perl.


              Читать дальше →
            • HAPRoxy для Percona или Galera на CentOS. Его настройка и мониторинг в Zabbix

              • Tutorial


              Очень короткая статья, про то как можно использовать HAProxy в качестве балансировщика для multi-master серверов MySQL, таких как Percona или Galera.



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


              Для тех кто не знаком с HAProxy, цитата о предназначении продукта:
              При увеличении нагрузки или посещаемости проекта, рано или поздно вертикальное маштабирование (увеличение ресурсов сервера, таких как память, скорость диска и т.д) упирается в некий предел и не дает ощутимого прироста. В таком случае в ход идет горизонтальное масштабирование — добавление новых серверов c перераспределением нагрузки между ними.
              Кроме увеличения мощности, горизонтальное масштабирование добавляет надежности системе — при выходе из строя одного из серверов, нагрузка будет сбалансирована между работающими и приложение будет жить.


              От слов к делу, установка и настройка очень просты:
              Читать дальше →