heathen

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

Так вот, что касается ZFS и быстродействия:

0.1. В первую очередь выбор будет решать поддержка ECC-памяти у вашего сервера-хранилища. ZFS очень критично относится к ошибкам RAM, а собственных механизмов для защиты от них у неё нет. Само собой, никто вам не гарантирует неприятности в случае отсутствия ECC, но единичные сбои в памяти - случаи не эксклюзивно редкие, поэтому решать вам.
0.2. Не используйте встроенные SATA-контроллеры. Купите LSA 3008 в IT-режиме и к нему всё цепляйте. Может быть, ваш имеющийся RAID-контроллер можно использоваться (но в JBOD-режиме, понятное дело), но он тоже может дать какой-то оверхед (если там даже для JBOD используется кэширование или ещё что хитрое).

1. Первое, во что стоит вложиться для оптимизации производительности чтения ZFS - это оперативная память. Больше памяти - быстрее операции чтения (ARC находится именно в памяти). Если у вас менее 16ГБ ОЗУ и возможности поставить больше нет - задумайтесь, нужен ли вам ZFS. Лучше вложить деньги в память, чем в SSD под L2ARC.
2. Для оптимизации операций случайной записи вам понадобится, как вы правильно заметили, SLOG, он же ZIL, на SSD. Правила следующие для него:
2.1. Во-первых, это должно быть устройство, предназначенное для ЦОД с максимально допустимым TBW (total bytes written). Не покупайтесь на дешевизну пользовательских SSD, это выйдет вам боком. Если говорить о Samsung, то смотрите в сторону 843 DC (именно DC, не Pro и не Evo), а лучше - Intel S3700. Учитывая, что вам нужен диск на 100GB - это не принципиально дорого получится. 1 DWPD и ниже - плохо, 3 - более-менее, 5-10 - отлично. Ну, и устройства для ЦОД имеют конденсаторы, поэтому при падении питания то, что в кэше диска, будет таки скинуто в основную память. Но повторюсь: обязательно смотрите условия гарантии и максимально допустимые объемы записи в день\всего.
2.2. По поводу того, что случится, если выйдет из строя устройство с ZIL. ZFS на запись работает следующим образом. Все транзакции, синхронные и асинхронные, кэшируются в памяти. В случае синхронных транзакций подтверждение приложению, отправившему транзакцию, будет отправлено только в случае завершения дисковых операций, в случае асинхронных - сразу же. Так вот, чтобы сократить время ожидания, ZFS скидывает каждую синхронную транзакцию на ZIL и отправляет приложению подтверждение. Теперь, если сервер неожиданно выйдет из строя, асинхронные транзакции будут потеряны (они только в памяти были), но вот синхронные будут восстановлены последовательно из ZIL и записаны на диск. Если же выйдет из строя SLOG-устройство, на котором у нас ZIL, во в процессе работы сервера, то ZFS запишет всё на диски основного массива из памяти, и далее начнёт использовать под ZIL основной пул.
Я это рассказал, чтобы вы понимали механику и смогли информированный выбор сделать. Т.е., с одной стороны, вы потеряете критичные данные только в том случае, если одновременно выйдет из строя SSD и сервер выключится по тем или иным причинам. Но если сервер включился, до перезагрузки существовала очередь синхронных транзакций, а SLOG-устройство неисправно, вы потеряете все незавершённые транзакции (что в случае с VM почти наверняка будет означать кучу проблем). Причём пул будет в аварийном состоянии, и вам придётся вручную его импортировать и "отмотать" назад до последней успешной транзакции. В качестве защиты можно поставить два SSD и mirror'ить zil между ними (прямо средствами ZFS), но это, понятное дело, снизит скорость.
Само собой, в случае проблем с диском (любым) вам и ОС ругаться будет, и ZFS том пометит как degraded. А превентивно - пользуйтесь smartmontools :-)
2.3. Большой ZIL вам не нужен, буквально несколько GB. Т.е. если у вас 1 диск, я бы отдал немного под систему, 5-10GB под ZIL, остальное - под L2ARC, если два диска, то зеркало под систему, зеркало - под ZIL (zpool add tank log mirror /dev/sda2 /dev/sdb2) и остатки на каждом разделе - под l2arc (zpool add tank cache /dev/sda3 /dev/sdb3). l2arc будет stripe'иться, что ещё увеличит скорость чтения.

Но, вообще говоря, 4 диска - это семечки для ZFS. На таком количестве дисков правильно подобранный SSD даже на операциях последовательной записи может дать прирост. Ну, и в случае хранилища под виртуализацию - только stripe + mirror, понятное дело. И маленький совет - купите пятый диск для hot spare. Просто на всякий пожарный.

Ну, и самое важное: качественный UPS must have.

P.S. Не используйте ZFS on Linux. Лучше Фря.

В результате эволюционно пришли к OpenStack + CEPH. ceph перед всем* остальным имеет ряд преимуществ:
- поддержка кластеризации за любом уровне - от диска -> до ноды -> до стойки -> до зала -> до датацентра -> до региона. Т.е. правилами можно настроить репликацию данных так, чтобы копии располагались как минимум один раз на любом необходимом уровне абстракции.
- устройства хранения в ceph можно добавлять подисково. Т.е. вам не нужно иметь RAID на каждом физическом хранилище, можно в любом момент добавить диск или его удалить, при этом данные автоматически ререплицируются для поддержания выбранной стратегии хранения. Само собой, RAID использовать можно, но это лучше делать для увеличения скорости, нежели для увеличения надежности. Скажем, если у вас SATA-диски, их можно запихнуть в RAID0 (stripe), и это, конечно, даст прирост производительности.
- в любой момент можно одной командой изменить минимальное количество распределенных копий данных для каждого отдельного пула (так называется аналог шары в ceph; т.е. всё хранилище данных разделено на пулы, доступ к которым может контролироваться отдельно), перестроение начинается немедленно; конечно, рекомендуется выставлять нечетное количество копий.
- у систем виртуализации присутствует программный интерфейс для доступа к RBD ceph, т.е. файловая система не должна поддерживать репликацию. в частности, мы сейчас используем openstack с kvm, у которого есть прямая поддержка rbd ceph.
- программные ноды и ноды хранения могут быть объединены; при этом, конечно, нужно иметь ввиду, что каждый object storage daemon (osd) требует 1GB памяти, и один физический диск - это один osd.

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

gadgetshieldz.com — я покупал эти плёнки, они на экран и на заднюю панель. Плёнки с влажным нанесением, после высыхания вообще никаких пузырей, на экране незаметна совершенно. В плюсах — после её наклейки телефон перестал сползать с Орба при зарядке. Покупал себе на Nexus 4 и девушке на iPhone, подошло всё изумительно.

Единственный минус — не очень дешево, $10 за полный комплект. Правда, из полного комплекта боковые части не стал оклеивать.

Присмотритесь к Proxmox (это KVM и OpenVZ). Если поставите рядом две идентичные машины и настроите DRBD — получите даже HA-кластер. Вполне рабочее решение.