seagull Опубликовано 26 марта, 2013 · Жалоба Задумался я тут о внедрении СХД, а то количество серверов растет, на одном дофига свободного места, на другом - наоборот не хватает. Денег особо не выделяется, так что аппаратные решения не рассматриваются. Соответственно, видится что-то вроде пары серверов, работающих зеркалом, на каждом сервере - массив RAID0, в случает отказа диска - избыточность восстанавливается с другого сервера. Для клиента естественно нужно автоматическое резервирование, то есть пофигу - упал один сервер, или второй - клиент продолжает работать. Да, физически сервера все в одном месте, связаны быстрыми надежными каналами. Требования к системе в порядке важности: 1. Отказоустойчивость. 2. ОТКАЗОУСТОЙЧИВОСТЬ!!! 3. Бесплатность (то есть GPFS не канает) 4. Скорость. Пока вырисовывается только GlusterFS, но есть от него ощущение какой-то сырости пока. Может у кого есть идеи по архитектуре, софту? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 26 марта, 2013 · Жалоба drbd + nfs ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 26 марта, 2013 · Жалоба drbd + nfs ? А как тут быть с прозрачностью для клиентов? Если сервер, с которого подмонтирована NFS упал? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 26 марта, 2013 · Жалоба heartbeat не дописал ;) у меня так сервера хранения для esx собраны - две машины, drbd+heartbeat и nfs... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 26 марта, 2013 · Жалоба heartbeat не дописал ;) у меня так сервера хранения для esx собраны - две машины, drbd+heartbeat и nfs... Ага, понял, пошел читать. А как опыт использования? Все как задумано работает, проблем не было? Нюансы никакие не вылезают при переключении активной ноды например, таймауты там какие-нибудь? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 26 марта, 2013 · Жалоба Никаких проблем не было. Хранилищ собрано 4, работают уже почти два года... И винты вылетали, и блоки питания горели, и контроллеры рейдов накрывались.. Работаем ;) Разве что у меня на каждой ноде 5-й рейд, но это уже дело вкуса по моему.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 26 марта, 2013 · Жалоба Почитал немного, и есть некоторое непонимание. Ну допустим подняли DRBD+heartbeat+NFS, раздали диск, на клиенте запустили MySQL например, с базой на NFS диске. Накрылась одна нода, поднялась вторая, запустила NFS, а как это выглядит со стороны MySQL? Таймаут/ошибка диска, перемонтирование раздела с другой ноды, переоткрытие файла базы, незавершенная транзакция, откат по бинлогу? Или не все так страшно, и все гладко проходит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 26 марта, 2013 · Жалоба Да, физически сервера все в одном месте, связаны быстрыми надежными каналами. Это плохо. Надо бы разносить сервера географически. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 26 марта, 2013 · Жалоба Надо бы разносить сервера географически. И поиметь split-brain? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 26 марта, 2013 · Жалоба Гластер вполне рабочий. Из недостатков на текущий момент: . в 3.3.1 сломали дисковый лимит по нодам, работает только лимит по папкам внутри тома . синхронный . гео репликация асинхронна, но при этом после завершения операции записи на мастере, мы можем иметь некоторую задержку при появлении данных на реплике. . если делать обычную destributed replication то не получите высокой скорости записи при высоком latency между нодами, если ваши ноды разнесены географически (в разных дц). . нет возможности на лету увеличить "избыточность" репликации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 26 марта, 2013 · Жалоба При переезде (и правильно настроенных таймаутах на heartbeat) - мускул увидит какие то тормоза с диском, а потом все будет работать дальше... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 27 марта, 2013 · Жалоба ceph, пускали и тестили на двух нодах, 3сетевых на гигабит в каждой, 16гб памяти, по десятку жестких. получили порядка 5тыс iops на чтение и запись. при нормальных дисках и хорошем контроллере можно отжать большье. для сравнения обычный диск в среднем дает порядка 140iops Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 27 марта, 2013 · Жалоба Гластер вполне рабочий. Из недостатков на текущий момент: Забыли упомянуть главный - он крутится в юзерспейсе. И как результат - медленный. Очень медленный. По сравнению с ядерными решениями типа DRBD. Зато разворачивается просто, да... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DobroFenix Опубликовано 27 марта, 2013 · Жалоба Используем сервер Synology с 8 дисками в RAID10, подключенный к XenCloudPlatform в виде iSCSI накопителя. Виртуалки работают быстро. HDTUNE под Windows внутри виртуалку говорит о производительности около 20000iops Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 27 марта, 2013 · Жалоба Надо бы разносить сервера географически. И поиметь split-brain? :) Ну это уж зависит от того, насколько нужна сохранность данных. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 27 марта, 2013 · Жалоба Забыли упомянуть главный - он крутится в юзерспейсе. И как результат - медленный. Очень медленный. По сравнению с ядерными решениями типа DRBD. Зато разворачивается просто, да. Все зависит от модели использования / дисков / фс на конечных нодах. Давно не трогал DRBD, но равзе там есть возможность на лету ввести еще одну машину, и ее диск "подцепить" к уже созданному устройству ? Можно ли там раскидать "реплику" к примеру на 3 машины и чтобы все работали в режиме master? С ceph все хорошо, но лично меня немного напрягают выделенные сервера метаданных на которых всё завязывается. Это оправданно, но при этом рождает дополнительные требования по обеспечению отказоустойчивости и доступности этих серверов, что не всегда подходит. Из вариантов есть еще pohmelfs с бэкендом в виде elliptics. Только модуль pohmelfs выпили из staging ядра начиная с ветки 3.4, и пока вроде не вернули :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 28 марта, 2013 · Жалоба Все зависит от модели использования / дисков / фс на конечных нодах. Не, ну если диски используются с практически нулевой нагрузкой - да, оно прекрасно подойдет. Иначе - тормозов огребетесь. Давно не трогал DRBD, но равзе там есть возможность на лету ввести еще одну машину, и ее диск "подцепить" к уже созданному устройству ? Можно ли там раскидать "реплику" к примеру на 3 машины и чтобы все работали в режиме master? Нет конечно. К слову - что, мультимастер в синхронном режиме будет быстрее мастер-слэйва? Или вы про асинхронный режим, в случае которого при записи в один и тот же блок может случиться диво дивное в виде непредасказуемой каши из важных данных? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 28 марта, 2013 · Жалоба Что-то тут все про DRBD, а про HAST никто и не вспомнил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 28 марта, 2013 · Жалоба Нет конечно. К слову - что, мультимастер в синхронном режиме будет быстрее мастер-слэйва? Или вы про асинхронный режим, в случае которого при записи в один и тот же блок может случиться диво дивное в виде непредасказуемой каши из важных данных? Не быстрее, вариант мастер - слейв наверно даже более "нагляден" и проще контролируем с точки зерния потоков данных. Но я просто привел пример когда нужно 3-4-5-6 копий данных, и также тот случай когда объем хранилища нужно нарастить без остановки сервиса. Gluster гарантирует консистентность данных в любом режиме, он не гарантирует время их появления на других нодах в асинхронном режиме. Проблемы с консистентностью и актуальностью данных могут возникнуть когда клиент сам является сервером. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...