« Rev
@ru_zfs   356
Fwd »


Alexander
а она ж сильно платная?
Вроде бы gratis? Сильно платный у них support, десятки кило зеленых, от скромности как грится не помрут, что в общем-то и хорошо для развития проекта. Все таки мелюсь между выбором Smart и Omni.
Alexander
Л2арк был?)
170 гиг на пром PCI express Intel SSD. 12 гиг рамы на сервере Kraftway для ZFS v0.6.x хранилища примерно 2005-2007 года выпуска. Он справлялся с рандомной нагрузкой СУБД (другой сервер 32 ядра и 48 гиг рамы) от которой в более крупных регионах дохли NetApp, которые на десять лет моложе. Но иногда уже не очень справлялся, особенно при пропусках дефграгментации, когда приходилось наверстывать упущенное. Как раз после перевода ПТК на мощные современные сервера разработчики покоцали базу данных почти в 5 раз, и более современные хранилища стали бэкапить ее всего в 2-3 раза быстрее после примерно пятикратного уменьшения размера :)
Mikhail
в целом да
ох... ZoL 0.8.5 на rhel 8.2, 8 сокетная система. Всё упирается в локи, то тут, то там. 1) aggsum -> osq_lock (писал выше) 2) taskq -> spin lock irqsave и его native slowpath. Я более 8 лет пользуюсь ZFS, но без нагрузки... а тут блин такое и если бы на своих сервера, а то у заказчика через кучу VDI-ев.
Alexander
ох... ZoL 0.8.5 на rhel 8.2, 8 сокетная система. Всё упирается в локи, то тут, то там. 1) aggsum -> osq_lock (писал выше) 2) taskq -> spin lock irqsave и его native slowpath. Я более 8 лет пользуюсь ZFS, но без нагрузки... а тут блин такое и если бы на своих сервера, а то у заказчика через кучу VDI-ев.
А SmartOS лишена таких недостатков? Сможет ли SmartOS проработать целый год под рандомной нагрузой промышленной СУБД типа Db2 или PG? При условии конечно, что не подведет незадублированное оборудование. Для меня очевидно, что нижним программным слоем хранения данных должна быть ZFS, но ZOL или Illumos, вот тут я не уверен ... Joyent вероятно патчит свою SmartOS быстрее, чем community типа OpenIndiana и OmniOS ? Все таки за саппорт стоимостью в десятки килобаксов им платят ведь не просто так?
Mikhail
И кто-то качественно, а кто-то...
Alexander
с 0.7 ещё по умолчанию фича флаги ломают загрузку грабом, смотрите любую офиц инструкцию по root on zfs для нужного списка
Попытался на Alpine 3.14 + ZFS 2.0.3 почти по инструкции: # zpool create \ -o ashift=12 -d \ -o feature@async_destroy=enabled \ -o feature@bookmarks=enabled \ -o feature@embedded_data=enabled \ -o feature@empty_bpobj=enabled \ -o feature@enabled_txg=enabled \ -o feature@extensible_dataset=enabled \ -o feature@filesystem_limits=enabled \ -o feature@hole_birth=enabled \ -o feature@large_blocks=enabled \ -o feature@lz4_compress=enabled \ -o feature@spacemap_histogram=enabled \ -o feature@zpool_checkpoint=enabled \ -O acltype=posixacl -O canmount=off -O compression=lz4 \ -O devices=off -O normalization=formD -O relatime=on -O xattr=sa \ test1 sde # grub-probe /mnt/d1 grub-probe: error: unknown filesystem. Другой пул из dd с моей рабочей станции: # grub-probe /mnt/d2 zfs
Alexander
смогет, стабильнее иллюмоса мало что есть
А что брать? Omni или Smart? IMHO Joyent в области поддержки ZFS on SunOS - это почти старая добрая Sun с такими же непомерными аппетитами до денег за поддержку, но при этом еще и с бесплатными подарками для нищебродов.
Alexander
Есть упоминания, что и с современным оборудованием SmartOS дружит получше, чем OmniOS, вероятно потому что у них более свежее ядро IllumOS ?
Alexander
Coming back to this after 6 weeks: we did not give up on illumos yet. In a way, I am grateful OmniOS botched that server upgrade. It forced us to either go back to FreeBSD world or try SmartOS. We are testing SmartOS and it has been quite good. Currently setting up an AMD server with Hetzner. SmartOS gives piece of mind by solving the upgrade problem tout cour. So, if your server's hardware can use SmartOS, give it a try. https://www.linuxquestions.org/questions/solaris-opensolaris-20/initial-omnios-impressions-by-a-bsd-user-4175626757/page4.html#post6110374
Міхаіл So
смартос и омниос работают отлично
Міхаіл So
сейчас кручу хранилку и апп сервера на омни ос поверх смартоса
Міхаіл So
все работает как часы
Alexander
сейчас кручу хранилку и апп сервера на омни ос поверх смартоса
Т.е. на железе Smart, а в гостевухе или zones Omni ?
Alexander
от сан там никого не осталось
Даже если рассматривать не инженеров, а по духу и вектору развития SunOS в компании.
Міхаіл So
с кентриллом и каллоу после покупки жоента самсунгом ушли почти все кто пришли работать из сан
Alexander
в основном квм
Он ведь там древний как оно самое? 2012 года?
Alexander
Oracle уже (впрочем как и вообще вероятно изначально) уже не торт: https://www.networkworld.com/article/3160176/game-over-for-solaris-and-sparc.html https://www.theregister.com/2017/09/04/oracle_layoffs_solaris_sparc_teams/ https://itsfoss.com/solaris-alternatives/
Міхаіл So
Чем это объясняется?
в самсунге так себе работать + началось всякое говно я хз что можно вообще рассказывать, но по сути начали заворачивать проекты жоента на внутреннюю самсунговскую тему
Міхаіл So
они подоили соляру, которая держится как раз на тех кто остался от сан, и забили
Alexander
В нем и была проблема - не рассчитал или не оставил достаточно пространства для сборщика мусора
Я пробовал разные варианты, это оказался наиболее скоростным. Таблицы L2ARC отъедали примерно 5 гиг по стате.
Alexander
Ты аллоцировал все доступное пространство
Осталось еще 7 гиг в раме (под ось, L1 ARC) и больше половины на SSD.
Міхаіл So
Очередной корпорастический "Oracle" :( Не дают спокойной жизни для SunOS.
ну они не забили, патчи от самсунга в иллюмос идут
Міхаіл So
солярис силами 10 человек наверное в оракле последние 10 лет живет
Міхаіл So
и те уже от старости просто свернулись
Alexander
Вот и причина
Предлагаешь уменьшить L2ARC до сотни? И так уже на пределе, база была 300-400 Гб. Без L2ARC вообще не шевелится.
Fedor
Если интересно - расскажу потом как делать чтобы не было таких эксцессов
Alexander
Есть бестпраксисы:)
Добавить оперативки за копейки, но ведь есть более важные статьи расхода типа всяких увеселительных мероприятий, театральных представлений и другой дичи.
Fedor
Хотя по что раз уже все всюду написали
Alexander
Хотя по что раз уже все всюду написали
Я не мог просто взять и добавить рамы, если ты об этом.
Alexander
Там бюджет на всякие писюковые мероприятия восновном. И цены еще невсегда конкурентноспособные. Где уж там моим серверным железякам. Просто для меня это было хобби, трудно найти еще что-то подобное non remote. Как-то еще чудом оказалось достаточно запасных HDD дисков и ни один пром. SSD не откинулся раньше времени. Все эти мероприятия как езда на одном колесе в цирке с точки зрения обеспеченности запаской.
Fedor
Я не мог просто взять и добавить рамы, если ты об этом.
Надо учитывать архитектуру используемого оборудования
Alexander
Надо учитывать архитектуру используемого оборудования
И результатом такого учета могло быть либо изучение ZFS либо неизучение, а нафик оно сдалось во втором случае. Кроме того даже штатные хранилки и гипервизоры вовремя не поставили к моменту ввода системы в эксплуатацию, поэтому мои "говно и палки" были единственным возможным вариантом, у меня даже есть письменные подтверждения от начальства.
Fedor
Особенности ее работы, нюансы сборщика мусора того же
Alexander
Архитектуру ССД
Самая скоростная PCI NMVE того времени, тыр по 70 за каждую вроде бы. Серверные enterprise PCI express Intel SSD, у них утилизация выше 4% никогда не поднималась :) Но в таком древнем серваке хранилки еще и шины тормознутые. Скорость работы пула в sync=standard и sync=disabled почти не отличалась, от силы процентов на 10%.
Alexander
SSD зеркало обслуживало SLOG, L2ARC и одновременно активные логи Db2.
Alexander
и те уже от старости просто свернулись
Вероятно Oracle Солярка уйдет на пенсию вместе с ее разработчиками, хоть бы не забыли заопенсорсить. К тому времени как раз OpenZFS и SmartOS станут shining super stars :)
Alexander
А никто не пробовал сделать HAST кластер из двух zvol на разных ZFS хостах? https://wiki.freebsd.org/HAST Будет ли это надежнее одиночного ZFS сервера? Например взять пару хранилок на базе SmartOS и объединить их zvols в HA HAST кластер? Причем фрюхи для HAST наверно можно запускать в гостевухах тех же самых SmartOS хранилок? И вроде даже собирались портировать HAST на Illumos: https://illumos.topicbox.com/groups/zfs/T871920870d073f68 Или DRDB в Linux чем-то хуже фрюшечного HAST? Раньше, когда спрашивал про HA для ZFS, мол только платно. Или как вариант CEPH, но без ZFS.
Fedor
если получилось бы, можно было б прям сделать апплаенс с чистым 2N.
Ivan
проблема в том, что это только на sas построить можно, а это существенно дороже.
Fedor
в виртуалках
не додумался тогда :( да и фигово там с отчётом о реальной записи на носитель - у меня после ребута зфс часто бился.
Alexander
не додумался тогда :( да и фигово там с отчётом о реальной записи на носитель - у меня после ребута зфс часто бился.
Разве в KVM есть проблемы с честностью синка? А bhyve неужели не сделали аналогично?
Fedor
может это конечно не совсем квм, а транспорт - дебажить тогда не стал
Fedor
там много факторов.
Fedor
мест, где это могло происходить, насчитал чуть ли не 4-5.
Ivan
Что именно?
нормальная двухголовая полка zfs строится на принципе одновременного доступа к диску по разным путям.
Fedor
и там даже головы не нужны для этого
Alexander
мест, где это могло происходить, насчитал чуть ли не 4-5.
Ну так пусть с железом контачит baremetal ZFS on SmartOS, а в виртуалке только проброс zvol.
Fedor
и там даже головы не нужны для этого
бэкплейны те же - та же история
Ivan
скази же. зфс тут не совсем играет.
так то что скази отдает как сделать отказоустойчивым ?
Fedor
так то что скази отдает как сделать отказоустойчивым ?
мультипатх это как раз фича сказявого протокола
Ivan
так это по езернету ж гонять данные меж полок придется ?
Fedor
в файберченнеле тоже. но мне кажется, файберченнел - только транспортная среда, не изучал этот вопрос
Alexander
нормальная двухголовая полка zfs строится на принципе одновременного доступа к диску по разным путям.
Это в идеале, но хотя бы просто кластер из двух узлов ZFS, хотя бы их между собой соединить 2-3 шнурками нетворка?
« Rev
@ru_zfs   356
Fwd »