У меня есть веб-сайт, который отслеживает в среднем 50 миллионов посещений в день, а в течение следующих 3 месяцев должно быть более 100 миллионов посещений в день. Мы пытаемся использовать GlusterFS v 3.0.0 (с последними патчами от 17.01.2010)
В настоящее время мы только что обновили среду балансировки нагрузки, которая имеет 3 физических хоста с 6 виртуальными машинами Xen-Server 5.5u1 (по 2 на каждом хосте) для обслуживания трафика веб-страниц. Каждая машина имеет 6 локальных накопителей Raid-6 (7200 об / мин-SATA). На старой машине, с которой мы пришли, был 1 зеркальный диск SAS 10k.
В настоящее время мы также установили GlusterFS с 3 блоками, по одному на каждом хосте, и он обслуживает 6 виртуальных машин в качестве клиентов. При тестировании вроде все нормально. Однако, когда мы перешли к производству, казалось, что доступного ввода-вывода просто недостаточно для обслуживания трафика даже свыше 15 миллионов обращений. Несколькими неделями ранее наш старый сервер мог обрабатывать трафик с максимальной скоростью 20M.
Есть ли какие-либо рекомендуемые конфигурации для такого приложения, или вещи, о которых следует знать, не очевидны в их документации на gluster.org для сайта нашего размера?
RAID-6 дисков 6x7,2krpm без кеша записи (?) Будет иметь ужасный производительность записи, настолько ужасная, что, вероятно, это приведет к тому, что диски опустятся настолько, что действительно повлияют на производительность чтения, если ваше приложение имеет здоровый микс. Я имею в виду, что на самом деле вы смотрите примерно на 250 случайных операций ввода-вывода в секунду в разделении чтения / записи 80/20 из этого массива. Если вы выполняете несколько сотен HTTP-запросов в секунду, тогда такая тривиальная вещь, как журнал доступа apache, может остановить это, как DoS-атака.
Если можете, переделайте их как raid10. Это будет стоить вам немного свободного места, но окажет огромное влияние на производительность ввода-вывода. И если вы можете получить кэш записи с резервным питанием от батареи на рейдовых картах, это будет иметь очень большое значение.
Я не знаком, в частности, с glusterfs, но все распределенные файловые системы, как правило, имеют одну и ту же основную проблему: сетевая задержка + сложная блокировка = низкая производительность, особенно для небольших файлов и особенно при больших рабочих нагрузках записи.
Медленный дисковый ввод-вывод и медленная файловая система, такая конструкция кластера просто не соответствует рабочей нагрузке. Уже поздно возвращать серверы или хотя бы дисковые подсистемы? Если это основная платформа для высокодоходной компании, вам действительно стоит привлечь профессионала.
На какой носитель вы перемещаете свой трафик GlusterFS? Если это Ethernet, ваша конфигурация будет сильно ограничена из-за накладных расходов TCP / IP. GlusterFS там не самый эффективный. Там, где это действительно хорошо, так это над RDMA. Вы можете добиться этого с помощью Infiniband или 10GigE.
Мне также немного непонятно, почему вы решили разместить 2 виртуальных хоста на каждом физическом хосте, если все они выполняют одни и те же обязанности. Почему бы просто не запустить их на голом металле и избежать накладных расходов?
Без более глубокого понимания вашей настройки (например, ваш веб-сайт статический или динамический? Проводятся ли транзакции с базой данных на серверах, использующих одну и ту же подсистему хранения?), Но RAID 6, как правило, плохой выбор для производительности записи, неважно, когда вы вводите еще большую сложность через блеск. У вас потенциально есть два набора трансляции полосы записи, один на уровне gluster и один на уровне контроллера. Затем у вас есть два вычисления четности, которые замедляют работу и вызывают блокировку ввода-вывода, если у вас нет большого кеша записи и периодов низкой активности ввода-вывода.
Я бы порекомендовал вам перейти на RAID 10 и вернуться к нему с помощью волоконно-оптического канала или нескольких связанных каналов GigE.
Какую версию GlusterFs вы используете? GlusterFS 3.0.0 является основным выпуском и имеет множество улучшений, включая повышение производительности при работе с небольшими файлами.
В GlusterFS есть множество трансляторов производительности, которые можно настроить для различных рабочих нагрузок. Например, для повышения производительности чтения у нас есть переводчик с упреждающим чтением, а для производительности записи - переводчик с отложенной записью. io-cache - еще один транслятор производительности, который можно использовать для кеширования.
Какой тип установки у вас? Вы используете репликацию или распространение или и то, и другое? Какой у вас сетевой сервер? Проверили ли вы производительность сетевого / дискового ввода-вывода между старым и новым серверами, чтобы устранить узкие места?
Если вы можете поделиться с нами своими файлами томов, мы поможем вам настроить файлы конфигурации для обеспечения оптимальной производительности для ваших рабочих нагрузок.
К сведению, мы предлагаем 30-дневную бесплатную пробную подписку на поддержку [1], где вы можете быстро и подробно ответить на свои вопросы.
Ура, Сачи