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