SergeiK Опубликовано 10 июля, 2016 · Жалоба Посмотрите на VMware-ский же VSAN. Вы жесткие диски тех же хостов под VmWare собираете и пользуетесь. И не надо лишних железяк. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
smelnik Опубликовано 10 июля, 2016 · Жалоба Вот только стоимость лицензии на vsan - 3000 $ за процессор + лицензии vsphere + vcenter. Не забываем, что лицензия standard у vmware полный отстой и нужно брать ent. Хотя есть бандлы ). В любом случае на 15 vm жирновато выходит. Мне кажется для нужд тс вполне хватит proxmox+drbd или hyper-v + storage spaces. Upd: прочитал, что у тс уже есть vsphere. Тогда пользуйте nfs+drbd. Благо с поддержкой nfs у vsphere все хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 11 июля, 2016 · Жалоба Open-E DSS возможно даже бесплатная на jbod, или платная на аппаратном рейде и даже с FC Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
FATHER_FBI Опубликовано 11 июля, 2016 (изменено) · Жалоба Не-не-не. Нормальный аппаратный рейд имеет минимум 6 физических портов, память и аккумулятор для кеша. Есть программная поддержка RAID 1|0|10|50|60. Речь идет о одновременном вылете двух SSD. RAID научились анализировать SMART ? Износ блоков? Все зависит от контроллера и SSD. Изменено 11 июля, 2016 пользователем FATHER_FBI Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 11 июля, 2016 (изменено) · Жалоба Являюсь тем кто построил и сапортит в данный момент 2 кластера и кучу разностных серверов, все на базе proxmox, сейчас over 500 клиентов которые приобретают услугу. К сожалению добиться качества получилось только используя ceph + intel ssd 800gb. Старое железо в том что числе схд на sas и ssd дисках где отдача идет по iscsi выдает такое количество проблем, что трудно представить. Вся проблема в том что до 100 клиентских VM проблем в обще нету, как только вы переходите эту цифру начинаются стуки. Для автора могу сказать такое: lsi контроллер локально, какой-то supermicro на 8 hotswap + 2 глухих кармана. Ставите туда 8 дисков sata обычных и делаете большой и толстый массив на базе контроллера. Для 20VM этого выше крыши. Если вам надо производительность, берете 2й сервер и вкидываете туда SSD, распределяете VM между этими двумя серверами и спитите спокойно. При желании берете 3й обычный сервак, без выпендрежа, вставляете пару дисков, поднимаете glusterfs на нем и отдаете на обе ноды где у вас VM, тем самым вы легко с простоем в пару секунд (время на перезапуск VM ) сможете мигрировать виртуалки между нодами. С помощью gluster миграция выглядит так: запускаем онлайн смену места хранения образа. после окончания миграции тушим VM на первой ноде. копируем конфиг VM на второу ноду. запускаем там эту VM мигрируем диск с glusterfs на основной storage. Все... простой только на выкл, вкл. Не надо городить кластера там где они не нужны, разбивайте машины между двумя независимыми нодами с различной производительностью дисковой подсистемы. Используйте локальное хранение работающих виртуальных дисков на аппаратных raid массивах. Создайте план по backup каждую ночь на выделенный сервер с glusterfs и спите спокойно. Изменено 11 июля, 2016 пользователем Megas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
FATHER_FBI Опубликовано 12 июля, 2016 · Жалоба Являюсь тем кто построил и сапортит в данный момент 2 кластера и кучу разностных серверов, все на базе proxmox, сейчас over 500 клиентов которые приобретают услугу. К сожалению добиться качества получилось только используя ceph + intel ssd 800gb. Старое железо в том что числе схд на sas и ssd дисках где отдача идет по iscsi выдает такое количество проблем, что трудно представить. Вся проблема в том что до 100 клиентских VM проблем в обще нету, как только вы переходите эту цифру начинаются стуки. Для автора могу сказать такое: lsi контроллер локально, какой-то supermicro на 8 hotswap + 2 глухих кармана. Ставите туда 8 дисков sata обычных и делаете большой и толстый массив на базе контроллера. Для 20VM этого выше крыши. Если вам надо производительность, берете 2й сервер и вкидываете туда SSD, распределяете VM между этими двумя серверами и спитите спокойно. При желании берете 3й обычный сервак, без выпендрежа, вставляете пару дисков, поднимаете glusterfs на нем и отдаете на обе ноды где у вас VM, тем самым вы легко с простоем в пару секунд (время на перезапуск VM ) сможете мигрировать виртуалки между нодами. С помощью gluster миграция выглядит так: запускаем онлайн смену места хранения образа. после окончания миграции тушим VM на первой ноде. копируем конфиг VM на второу ноду. запускаем там эту VM мигрируем диск с glusterfs на основной storage. Все... простой только на выкл, вкл. Не надо городить кластера там где они не нужны, разбивайте машины между двумя независимыми нодами с различной производительностью дисковой подсистемы. Используйте локальное хранение работающих виртуальных дисков на аппаратных raid массивах. Создайте план по backup каждую ночь на выделенный сервер с glusterfs и спите спокойно. Поделитесь своими впечатлениями работы с ceph, много читал за него, проект молодой и мало примеров инсталляций. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tokra Опубликовано 14 июля, 2016 (изменено) · Жалоба ЧТо ceph, что glusterfs, да и все похожие проекты есть смысл, если вам нужен большой кластер, на много много много дисков, при чем строить надо не так, что к одному серваку подцепим полку из 30 дисков и ***ись, а один-два диска - один сервер, что бы при выпадении сервера, кластер не ребалансил его 30 дисков по 2-3 тера. Вообще в тестах под нагрузкой добились того, что ceph кластер не собрался, ибо когда выпал сервак, на котором было дисков суммарным объемом в 40 терабайт (данных было 70% где-то), при ребелансе большого объема данных начали сыпаться диски в других серверах, ибо диски уже имели наработку. Короче проблемы все те же, что и в рейд массивах, только не локально, а размазано по серверам) Там у каждого решения столько своих подводных камней, что жопой жуй. Вон ceph блюстор пилят, они замахнулись на то, что хранить данные в диске они будут сами, минуя фс системы. Тыц glusterfs libgfapi + qemu/kvm очень неплохо работает, с десяток нод в виртуалками, их диски собраны в пул, с репликой, сеть 10Г между нодами. Пока сплитбрейн не ловили, хотя люди грешат на гластер именно по этой проблеме. Изменено 14 июля, 2016 пользователем tokra Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 15 июля, 2016 (изменено) · Жалоба Мы столкнулись с рядом проблем при использовании glusterfs в качестве сторежджа для vm в proxmox, очень часто виртуалки не поднимались или глючи, как только меняешь сторедж сразу все становится нормально. Я помню момент когда gluster не поддерживался kvm, это было года 2 назад, потом появилась поддержка, но проблемы явно сохранились. По этому использовать glusterfs как сторедж не рекомендую, но может у кого-то есть другой опыт. Впечатления от ceph двоякие, как уже сказал были и взлеты и падения, благо на ssd дисках бэкап клиентских виртуалок пролетает за 12 часов на внешние стореджы и после этого сплю спокойно. Даже если ceph крякнется, просто переразверну виртуалки. Но, мы вывели форумулу для себя при которой у нас оптимальное количество OSD и нод, выше головы прыгать нет желания, по этому как только заполнили кластер, то строим просто другой. Примеров инсталяции ceph очень много, просто вы в них не вникали, но и проблем много, никто не готов тратится на InfiniBand и большие толстые хранилища. tokra правильно описал проблемы и требования. 10г это минимум что надо, потом обязательно точное время, лучше несколько штук, мы сейчас городим на базе gps датчиков 2 сервера точного времени в кластера, не хотим больше не от кого зависеть кроме воздуха. Что касается дисков, то при использовании sata или sas в больших обьемах их все же лучше подключать через raid контроллеры, тогда если сдохнет диск это будет больше контроллера, а не всего ceph кластера. Понятно что можно перекрутить кучу параметров, приоритетов, но по опыту скажу, в задницу, osd на raid через аппаратный контроллер, конфигурации raid по желанию, хоть 0, хоть 10, остальные конфигурации бесмысленны. Но прежде чем строить системы такого плана, ответьте себе на вопрос, какая у вас будет нагрузка, сколько iops вы хотите получить и сможете ли выделить 10г минимум сеточку, ибо на 1Г конечно можно, но не приятно до ужаса при объеме. Думал писал, похоже нет. Текущие показатели внутри виртуалки выглядят примерно как 120-200тыс iops на чтение, и порядка 15тыс iops на запись, порядка 800мегабайт чтение с диска виртуального на rdb пуле и порядка 300 на запись. Увы, ceph, ssd не любят линейные данные, только качественный random. SSD по 800гб сейчас порядка 15шт, планирую увеличить до 18шт. К сожалению пределы системы пока не поймал, но текущего хватает выше крыши, бэкапы главное идут без всяких тормозов, негатива от клиентов в сторону ceph и производительности не было еще, в отличии от внешнего хранилища и iscsi. Изменено 15 июля, 2016 пользователем Megas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
