У меня есть несколько веб-серверов, которые используют множество небольших файлов для создания динамических веб-страниц. Кэширование веб-страниц невозможно. Веб-сервер также выполняет записи, поэтому мне нужна синхронная файловая система.
Я стремлюсь максимизировать производительность, поскольку, насколько я понимаю, небольшие файлы являются слабым местом (в разной степени) кластерной файловой системы через Ethernet.
В настоящее время я использую Centos 5.5, 64 бит.
Так как это всего лишь около 300 МБ данных, я смотрю на mdadm, использующий RAID-1 с GNBD и локальный жесткий диск с параметром «--write-most», поэтому чтение выполняется с локального жесткого диска.
Это возможно?
Если да, то есть ли преимущества в том, чтобы сделать его диском tmpfs вместо локального жесткого диска?
Или файлы на локальном жестком диске все равно будут кэшироваться в ОЗУ, поэтому я не увижу прирост производительности при использовании tmpfs, если имеется достаточно ОЗУ?
Я предлагаю вам взглянуть на Glusterfs. Я использую его для 1) прозрачности - это резервное хранилище, если хотите, обычная файловая система, такая как ext3; 2) доступность данных - glusterfs обеспечивает чередование, репликацию или любую их комбинацию; 3) производительность и надежность и 4) простота использования.
Хотя вы можете использовать его в режиме (веб-сервер) клиент / (файл-сервер), в зависимости от скорости вашей сети, для меня было бы разумнее включить его на каждой машине. В некотором смысле окончательным источником становится файловый сервер. Каждый веб-сервер читает и записывает на свой собственный локальный сервер glusterfs или, по крайней мере, в свой собственный кеш на локальных скоростях ввода-вывода и на файловый сервер на сетевых скоростях, что делает систему довольно быстрой.
Он может использовать tcp или Infiniband. И вроде работает под Amazon Web Services. Он также экспортирует NFS и CIFS, поэтому может быть довольно портативным. Установите через yum под CentOS, и запускается менее чем за 20 минут. По сравнению с GNBD, его намного проще настроить и использовать. Glusterfs имеет модульную конфигурацию, поэтому вы можете использовать только то, что вам нужно.
Прелесть glusterfs в том, что она очень терпима к отключениям сети или хоста. В моем бизнесе whcreative.com я использую его для частично мобильных ноутбуков, обслуживающих домашние каталоги, а также файловые системы html и баз данных (для Drupal CMS) в смешанной среде с CentOS 5.5, Fedora 13 и другими различными разновидностями Linux. Домашние каталоги обслуживаются с каждого ноутбука, а также с сервера. Когда ноутбук повторно подключается после использования вне сети, простой> ls -Rl на сервере синхронизирует все. Если машина выходит из строя и файловая система ext4 потенциально имеет устаревшие данные, это не проблема, поскольку синхронизация с вышедшей из строя машиной, когда она оживает, решает проблему довольно быстро.
Первый недостаток в том, что он протестирован только на x86_64 (заявлено, что он работает на i386). Но для большинства это не большая проблема. Самый большой недостаток - это документация. Например, отсутствует справочная страница с описанием одной из ключевых команд, glusterfs-volgen, а страница «похожая на человека» на веб-сайте не содержит рабочего синопсиса, хотя и содержит примеры. Параметры конфигурации четко не задокументированы, и для их определения потребуется немного взлома. Последний недостаток заключается в том, что он по существу полагается только на разрешения пользователя для обеспечения безопасности. Но по традиции * nix довольно легко запустить внутри VPN, так что это не такая уж большая проблема.
За надежность не ручаюсь, пользуюсь всего несколько месяцев. Однако, похоже, он отлично справляется с нашими домашними каталогами после отключения, использования ноутбука и повторного подключения. Конечно, я не доверяю ему полностью и делаю резервные копии на основе tar в файловую систему CentOS, ext3.
Удачи, Эрик Човански
Я удивлен, что вы считаете, что кеширование не подходит для всего лишь 300 МБ данных. Вы можете разместить это в оперативной памяти за 50 долларов (и это при условии, что вы не ищете что-то дешевое)
Еще вы можете подумать о добавлении RAM-диска в RAID-массив. Вы можете иметь столько устройств в массиве RAID 1, сколько хотите, поэтому у вас может быть RAM-диск, локальный физический диск и GNDB в RAID 1.
Однако неясно, каковы ваши требования. Вам нужна высокая производительность чтения и записи, у вас несколько веб-серверов. Связаны ли веб-серверы каким-либо образом? Почему один из дисков в вашем массиве подключен к сети, если вам в первую очередь нужна производительность?
RAID-1 только увеличит производительность чтения, но не записи. / tmp все равно стирается, поэтому используйте tmpfs в / tmp. Также, если вас не волнует избыточность, используйте RAID-0 (с чередованием) и укажите низкий размер блока, поскольку у вас есть небольшие файлы.
Чтобы ответить на последнюю часть вашего вопроса, нет, я не думаю, что вам нужно использовать tmpfs. При отсутствии других требований к памяти, Linux будет хранить файлы в своем кэше страниц после того, как они будут прочитаны в первый раз.
Настоящий вопрос здесь, кажется, такой: «У меня есть набор файлов, которые я часто читаю, но редко записываю, которые мне нужно синхронизировать между машинами. Как я могу это сделать?»
Интересные предложения кажутся
Из этих идей я предпочитаю простоту сервера NFS. Я выкину еще одну - используйте lsyncd (или какой-либо другой инструмент на основе inotify) для запуска синхронизации при добавлении файла. Lsyncd позволяет легко выполнять синхронизацию через rsync, но, к сожалению, это не подходит для синхронизации в нескольких направлениях. csync2 инструмент, созданный для этого, и его можно интегрирован с lsyncd.
Возможно ли программное обеспечение Raid1 с использованием mdadm с локальным жестким диском и GNDB?
Ответ: 42Возможно для любого блочного устройства ПЕРИОД