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