Файловая система Btrfs является прямым конкурентом ZFS и обладает практически теми же функциями, за исключением того, что дополнительно дает возможность просмотреть список файлов, которые изменялись с момента последнего снапшота.
Да, gui с Самбой не работает, и вряд ли будет работать (может быть в далёком будущем). Ещё одна деталь — чтобы CIFS убрать полностью (то есть, чтобы никто не мог его случайно опять включить — имеет смысл удалить конфиг сервиса ис SMF: svccfg delete smb/server.
Если надо, сервис потом можно восстановить: svccfg import /var/svc/manifest/network/smb/server.xml
Ага, понятно. Проблема тут как раз в том, что kernel CIFS поддерживает только Active Directory. Чтобы система работала с другими LDAP доменами, надо использовать Samba (smbd) вместо CIFS (SMF smb/server), что достаточно нетривиально настроить, и официально не поддерживается для Enterprise. После этого, насколько я понимаю, конфигурация домена задаётся в smb.conf. К сожалению, помочь с этим никак не смогу — я Самбой никогда не занимался.
rsync обычно работает сам по себе поверх TCP, ssh там очень опционально. Но синхронизация файлов (которым надо хеши считать) vs блоков (у которых, наверное, есть карта с таймстемпами последних изменений) — это понятно.
Ну да, примерно так и есть — изменённые блоки в ZFS получить очень легко. Исторически, send/receive был написан одним парнем в Sun, которого сослали в Китай, и он таким образом решил проблему с синхронизацией репозитория кода Solaris между локальной системой и главным офисом. :)
А что, кстати, у нексенты с тех-поддержкой на русском и с русской бухгалтерией?
Первый уровень тех-поддержки и бухгалтерия сейчас работают в основном через местных партнёров, насколько я знаю. Поскольку продажи в России растут, возможно скоро будут и местный саппорт, и бухгалтерия, но непонятно, когда. Ну и я тоже в тех поддержке (L3), если проблема сложная. А так, ребята могут и Google Translate использовать.
В компании есть, кто может настроить до нужного состояния что угодно. Но у меня нет понимания длительности процессов в обоих случаях, и есть подозрение, что поставить нексенту будет быстрее.
Скорее всего, да, быстрее. Solaris всё-таки сильно отличается от Linux. Доразвить альтернативу — это примерно как выбрать Gentoo вместо того, чтобы купить Redhat. Иногда имеет смысл (например, создатель OpenIndiana работает в EveryCity Hosting, и изначально строил систему для внутреннего использования); иногда — нет.
А чем он лучше для этого, чем rsync? Более того, в документации утверждается, что rsync лучше:
AutoSync использует ZFS send/receive, и передаёт измененные блоки между снэпшотами. Rsync смотрит на каждый файл и передаёт изменённые файлы. Так что rsync не сможет ничего сделать с iScsi/FC zvol'ами. Кроме того, rsync сам работает поверх ssh, так что он обычно медленнее, особенно для репликации между удаленными сайтами. И, поскольку он работает с файлами, он не очень подходит для репликации, если на системе миллионы маленьких файлов.
Контекст вопросов — я давно пытаюсь понять практический смысл платной нексенты
Тех-поддержка и помощь с настройкой. Если вы интимно знакомы с ZFS и Солярис, делайте систему на OpenIndiana или OmniOS. Принцип здесь тот же как и XenServer vs. XCP, или Redhat vs. Centos. Для небольших систем имеет смысл купить поддержку, особенно если в компании нет никого, кто может нормально настроить и поддерживать систему вручную.
Я весьма мало понимаю в нексенте, но правильно ли я понял из документации, что AutoSync есть механизм репликации между двумя железками и в реальной жизни не особо нужен в масштабах одной единственной железки?
В принципе да, он для репликации между железками, но его можно использовать и для Local to Local репликации. Например, делать бэкапы с быстрого 15к пула на медленный пул из 2-3-4ТБ дисков.
А какие еще плагины нужны в реальной жизни хостинга (именно хостинга, а не в корпоративной среде, например, банков)?
Для хостинга имеет смысл взять HA Cluster, и может быть FC Target, если планируете делать Fibre Channel. Есть ещё VMDC, но он практически бесполезен если есть vCenter или Xen Enterprise.
Так raidz — это и есть Raid5, грубо говоря. Несколько raidz групп в одном пуле — получается аналог Raid50. То, что группы маленькие, по 3 диска — это хорошо, там вероятность потери 2х дисков в группе из 3х небольшая, не больше чем потеря 2х дисков в одной mirror группе. Но тем не менее, она есть, так что регулярные бэкапы всё равно необходимы.
Окей, замечательно. Только «в курсе всех косяков» — понятие растяжимое. У партнёров пока нет прямого доступа в наш внутренний багтрекер, так что с некоторыми косяками они могли и не встречаться. Особенно с точки зрения производительности — есть некоторые мелочи, которые могут её поднять в разы, если известен workload.
Например: правильная настройка mpxio (scsi_vhci.conf), размер блоков на LUNах (достаточно нетривиально понять, что больше подходит), правильные параметры для ZFS в /etc/system, и так далее.
А вот это вы зря. Компрессия (on/lzjb) практически ничего не стоит с точки зрения CPU, но места может сэкономить достаточно много (для виртуалок, 1.5х compress ratio — запросто). В отличии от дедупликации, которой нужны дорогие SHA256 вычисления для каждого I/O, и большой кеш.
С gzip всё будет медленно, да, он подходит только для архивов, где производительность не особо важна.
Опытные люди говорят что нужен серверный ssd или будут проблемы.
Подтверждаю :) 710 или 520 — нормально для standalone системы; всякие там 320/311/… нормально работать не будут, или будут, но недолго.
Емкость пула можно расширить в любой момент добавлением новых дисков. Это не драматическое событие при расширении RAID6 емкостью 10Tb на традиционном контроллере, вы просто добавляете еще дисков и система начинает их использовать. Ничего не перестраивается, данные никуда не перемещаются.
На версии 3.1.3.5 расширение пула делать не советую, особенно когда он почти забит данными. Там используется достаточно старый алгоритм аллокатора, который не делает правильную балансировку на vdev'ы разной степени заполненности. Когда выйдет 3.1.4 или 4.0, можно проапгрейдиться, там новый алгоритм, который это учитывает.
Enhancement 12379: Enhanced the ability of ZFS to handle imbalanced LUNs which can occur when a user has grown zpools after creation which could have led to poor performance.
Немного непонятно, с таким подходом для storage и compute всё равно используются разные физические сервера, так? А не думали над вариантом объединить storage и compute? То есть, вместо скажем 1U или блейд-серверов для машин клиентов и 2U-4U нод для стораджа, использовать 1U/2U ноды с дисками для всего вместе — диски и часть сетевых портов отделить для распределённого хранилища (можно даже сам сторадж сделать на virtual appliance с raw disk passthrough), а CPU и большую часть RAM оставить на контейнеры клиентов.
Ага, есть такое дело, сталкивался пару раз. Для (Open)Solaris придумал достаточно некрасивый, но работающий хак:
echo zfs_no_scrub_io/W0t1 | mdb -kw
После этого надо дать resilver закончиться (он пройдёт достаточно быстро), и «zpool offline» сбойное устройство.
Потом поменять параметр назад:
echo zfs_no_scrub_io/W0t0 | mdb -kw
и «zpool replace» его работающим диском.
Принцип работы хака: в треде, где идёт resilver, мы пропускаем собственно часть, которая пишет данные; resilver заканчивается (естественно, на битый диск мы ничего не пишем, так что ошибок на нём не будет, но и данных тоже).
Если проблема именно в latency, можно попробовать поиграться с zfs_vdev_max_pending — этот параметр контролирует queue depth дисков. Таким образом можно уменьшить среднюю latency дисков. Зависит от модели дисков и от того, как они обрабатывают внутреннюю очередь.
Также обязательно посмотреть на iostat и zpool iostat — надо убедиться, что когда мы читаем данные, ничего не пишется одновременно — atime timestamp, например. Ну а дальше — искать bottleneck с DTrace и думать.
zfs diff [-FHt] snapshot snapshot|filesystem
Если надо, сервис потом можно восстановить: svccfg import /var/svc/manifest/network/smb/server.xml
Ну да, примерно так и есть — изменённые блоки в ZFS получить очень легко. Исторически, send/receive был написан одним парнем в Sun, которого сослали в Китай, и он таким образом решил проблему с синхронизацией репозитория кода Solaris между локальной системой и главным офисом. :)
Первый уровень тех-поддержки и бухгалтерия сейчас работают в основном через местных партнёров, насколько я знаю. Поскольку продажи в России растут, возможно скоро будут и местный саппорт, и бухгалтерия, но непонятно, когда. Ну и я тоже в тех поддержке (L3), если проблема сложная. А так, ребята могут и Google Translate использовать.
Скорее всего, да, быстрее. Solaris всё-таки сильно отличается от Linux. Доразвить альтернативу — это примерно как выбрать Gentoo вместо того, чтобы купить Redhat. Иногда имеет смысл (например, создатель OpenIndiana работает в EveryCity Hosting, и изначально строил систему для внутреннего использования); иногда — нет.
It depends ©.
AutoSync использует ZFS send/receive, и передаёт измененные блоки между снэпшотами. Rsync смотрит на каждый файл и передаёт изменённые файлы. Так что rsync не сможет ничего сделать с iScsi/FC zvol'ами. Кроме того, rsync сам работает поверх ssh, так что он обычно медленнее, особенно для репликации между удаленными сайтами. И, поскольку он работает с файлами, он не очень подходит для репликации, если на системе миллионы маленьких файлов.
Тех-поддержка и помощь с настройкой. Если вы интимно знакомы с ZFS и Солярис, делайте систему на OpenIndiana или OmniOS. Принцип здесь тот же как и XenServer vs. XCP, или Redhat vs. Centos. Для небольших систем имеет смысл купить поддержку, особенно если в компании нет никого, кто может нормально настроить и поддерживать систему вручную.
В принципе да, он для репликации между железками, но его можно использовать и для Local to Local репликации. Например, делать бэкапы с быстрого 15к пула на медленный пул из 2-3-4ТБ дисков.
Для хостинга имеет смысл взять HA Cluster, и может быть FC Target, если планируете делать Fibre Channel. Есть ещё VMDC, но он практически бесполезен если есть vCenter или Xen Enterprise.
Так raidz — это и есть Raid5, грубо говоря. Несколько raidz групп в одном пуле — получается аналог Raid50. То, что группы маленькие, по 3 диска — это хорошо, там вероятность потери 2х дисков в группе из 3х небольшая, не больше чем потеря 2х дисков в одной mirror группе. Но тем не менее, она есть, так что регулярные бэкапы всё равно необходимы.
Например: правильная настройка mpxio (scsi_vhci.conf), размер блоков на LUNах (достаточно нетривиально понять, что больше подходит), правильные параметры для ZFS в /etc/system, и так далее.
А вот это вы зря. Компрессия (on/lzjb) практически ничего не стоит с точки зрения CPU, но места может сэкономить достаточно много (для виртуалок, 1.5х compress ratio — запросто). В отличии от дедупликации, которой нужны дорогие SHA256 вычисления для каждого I/O, и большой кеш.
С gzip всё будет медленно, да, он подходит только для архивов, где производительность не особо важна.
Подтверждаю :) 710 или 520 — нормально для standalone системы; всякие там 320/311/… нормально работать не будут, или будут, но недолго.
На версии 3.1.3.5 расширение пула делать не советую, особенно когда он почти забит данными. Там используется достаточно старый алгоритм аллокатора, который не делает правильную балансировку на vdev'ы разной степени заполненности. Когда выйдет 3.1.4 или 4.0, можно проапгрейдиться, там новый алгоритм, который это учитывает.
echo zfs_no_scrub_io/W0t1 | mdb -kwПосле этого надо дать resilver закончиться (он пройдёт достаточно быстро), и «zpool offline» сбойное устройство.
Потом поменять параметр назад:
echo zfs_no_scrub_io/W0t0 | mdb -kwи «zpool replace» его работающим диском.
Принцип работы хака: в треде, где идёт resilver, мы пропускаем собственно часть, которая пишет данные; resilver заканчивается (естественно, на битый диск мы ничего не пишем, так что ошибок на нём не будет, но и данных тоже).
Также обязательно посмотреть на iostat и zpool iostat — надо убедиться, что когда мы читаем данные, ничего не пишется одновременно — atime timestamp, например. Ну а дальше — искать bottleneck с DTrace и думать.