После годового затишья увидел свет (http://gdamore.blogspot.com/2011/07/nexentastor-31-available...) релиз дистрибутива для создания сетевых хранилищ NexentaStor 3.1 (http://www.nexentastor.org/projects/site/wiki/CommunityEdition), сочетающего в себе ядро OpenSolaris и программное окружение Ubuntu 8.04. В качестве файловой системы используется ZFS, для работы пакетами используется пакетный менеджер APT. Управление системой производится через удобный web-интерфейс. Размер установочного iso-образа (ftp://ftp.nexentastor.org/www/releases/NexentaStor-Community...) составляет 580 Мб, для использования системы требуется минимум 768 Мб ОЗУ.
Данный выпуск является последним, основанным на ядре OpenSolaris, следующая версия дистрибутива будет основана на ядре, развиваемом в рамках проекта Illumos (http://www.illumos.org/) (развиваемый сообществом (http://www.opennet.me/opennews/art.shtml?num=27515) форк OpenSolaris). Кроме того, через несколько недель планируется выпустит...URL: http://gdamore.blogspot.com/2011/07/nexentastor-31-available...
Новость: http://www.opennet.me/opennews/art.shtml?num=31352
стыд, 768 мб минимум, подурели
это больше требования ZFS, она любит память. не такие уж это и большие деньги на сегодня.
у мну виртуалкам выделено 156М ОЗУ.
ZFS нормально пашет.
Это какой-то совершенно нетипичный случай. Для нормальной работы ZFS надо гига два минимум.
> Это какой-то совершенно нетипичный случай. Для нормальной работы ZFS надо гига два
> минимум.Вы определитесь в терминах. Что такое "нормальная" работа?
>> Что такое "нормальная" работа?Нормальная работа это полсотни шпинделей.
А что?
Можно ограничить использование памяти ARC своей спецификой системным параметром и параметрами собственно ZFS. И это вовсе не 2 Гб.
>у мну виртуалкам выделено 156М ОЗУ.
>ZFS нормально пашет.На 4Гб виртуальном же диске? С одним юзером и без нагрузки?
Понятия о нормальном у всех разные. Нет, как-то оно конечно и на 156Мб наверное запустится. Вот только скорость работы будет паршивая.
> Понятия о нормальном у всех разные. Нет, как-то оно конечно и на
> 156Мб наверное запустится. Вот только скорость работы будет паршивая.Не надо ля-ля, радость моя. Зависит от приложения и настроек датасетов и сторидж пулов.
http://download.oracle.com/docs/cd/E19253-01/820-0836/gitgn/...
>768 МБ – минимальный объем памяти, необходимый для установки корневой файловой системы ZFS.
>Для оптимизации общей производительности ZFS рекомендуется использовать 1 ГБ памяти.
>Рекомендуется использовать по крайней мере 16 ГБ дискового пространства. Пространство используется следующим образом:
>....повторю - по крайней мере 16 ГБ дискового пространства
зыж
оракл любезно для лолякольщиков доку даже на русский перевёл.
а им всё ни по чём, лишь бы на форуме потрындеть.
Не смешите. Сейчас столько памяти на смартфонах, не то что на сетевых хранилищах.
Да и вообще, линукс на меньшем количестве памяти и не запускается. Проверял только на Ubuntu.
у нас в хранилище 256 мб ОЗУ, 14 HDD, ext3, centos 5
Debian Lenny прекрасно запускается и работает на 192Мб. Если в системе хотя бы 512 метров рамы — запустится и будет работать с более-менее приличной скоростью любой дистрибутив. Больше — под особые задачи.
> Да и вообще, линукс на меньшем количестве памяти и не запускается. Проверял
> только на Ubuntu.Интересно, как же тогда работает вон тот adsl-модем с 16Мб и линуксом? Ты не только дурак но еще и лжец?
Linux RHEL6/64 - попытка загрузить ее в виртуалке с 1G RAM закончился OOM на этапе загрузки init.
а тут хотят всего 768 - то есть на 300м меньше, мелочь - а приятно.
Как странно, а у меня грузится :) ЧТЯНД?
> Linux RHEL6/64 - попытка загрузить ее в виртуалке с 1G RAM закончился
> OOM на этапе загрузки init.Вообще-то в требованиях 512Мб. И OOM на фазе загрузки инита выглядит странно. Кто-то где-то пытается нас нае... ?
Знаете... Некоторые идиоты ставят на сервера 64+ гигабайта оперативки. Базы данных. ПОЗОР! Совсем разучились программировать. То ли дело раньше... Возьмёшь, доставишь ещё 32 мегабайта и всё летает...А если серьёзно - у ZFS, по сегодняшним меркам, очень гуманные требования. Особенно если учесть те преимущества, что она даёт. Если вы не готовы для нужд "какой-то ФС" выделить нужные ей ресурсы (ведь это всего лишь ФС, ага) то сидите на EXT2/FAT - вас никто не толкает. Не жалуйтесь потом, что вас эти ФС не устраивают по функционалу/скорости.
P.S. Это ответ не только данному конкретному Анониму, но всем тем, кто кричит про завышенные требования многих проектов.
> не толкает. Не жалуйтесь потом, что вас эти ФС не устраивают
> по функционалу/скорости.Бенчмарки zfs не показывают ничего хорошего. Что, кеш на 16 гигз ей дать? Чувак, а рамдиск на 16 гигз - так вообще ракета просто. Только дороговато в пересчете на гиг и все-равно, или данные лезут в оперативку и на ФС вообще фиолетово, хоть фат. Или не лезут и вот тут мы уже ощущаем на себе ее свойства в плане производительности. У zfs они довольно вялые, что и демонстрируют многочисленные бенчмарки.
Самое забавное что оно склонно к фрагментации за счет принципа работы, а дефрагера до сих пор нет. Видимо предлагается дикими буферами вытягивать. Ну с таким подходом можно вообще рамдиском пользоваться. Станет еще круче.
Мой опыт: 5,5TB хранилища с относительно сложной структурой (зеркала/страйпы средствами самой ZFS) + 1GB памяти. Нехватки по памяти даже при высокой нагрузке нет. Проблем с фрагментацией тоже нет. Производительность - дисковая. )
Вижу разницу между 5,5TB рамдиском и одним системным гигабайтом + диски как по стоимости так и по скорости. )
>> не толкает. Не жалуйтесь потом, что вас эти ФС не устраивают
>> по функционалу/скорости.
> Бенчмарки zfs не показывают ничего хорошего. Что, кеш на 16 гигз ей
> дать? Чувак, а рамдиск на 16 гигз - так вообще ракета
> просто. Только дороговато в пересчете на гиг и все-равно, или данные
> лезут в оперативку и на ФС вообще фиолетово, хоть фат. Или
> не лезут и вот тут мы уже ощущаем на себе ее
> свойства в плане производительности. У zfs они довольно вялые, что и
> демонстрируют многочисленные бенчмарки.А из коробки она и не должна при размере рекорда 128К что-то приличное показывать. Настраивать ее надо, чувак. Знаешь ли.
> Самое забавное что оно склонно к фрагментации за счет принципа работы, а
> дефрагера до сих пор нет. Видимо предлагается дикими буферами вытягивать. Ну
> с таким подходом можно вообще рамдиском пользоваться. Станет еще круче.Ты трындишь. Знаешь, поччему? Это экстентная ФС, а они не фрагментируются по умолчанию. Давай ты сделаешь одну вещь - иначе я считаю тебя свистоболом - покажи инструментальные измерения уровня фрагментации. Ага?
И заодно - принцип работы, благодаря которому она склонна к фрагментации - покажи-ка. Желательно со ссылками на сорцы ZFS. Ага?
>Ты трындишь. Знаешь, поччему? Это экстентная ФС, а они не фрагментируются по умолчанию.слышал звон, да не знаешь где он.
бтр - вот она экстентная - http://en.wikipedia.org/wiki/Btrfs#Extents
со своим extent allocation tree, и (как говорят - пока) красно-чёрными деревьями, которые в ядре линуха широко используются.
за что её кстати и критиковали, типа - фиг у вас получится быстро и эффективно.
но получилось.
а zfs - блочная. с переменным блоком? Да.
COW? Да.
И вот из-за последнего она как раз и меньше подвержена фрагментации. Как и бтр.
И как и бтр склонна к фрагментации в граничных условиях.
для чего в бтр и встроили Online defragmentation - http://en.wikipedia.org/wiki/Btrfs#Features
зыж
с такими познаниями только щёки и надувать. угу.
> Знаете... Некоторые идиоты ставят на сервера 64+ гигабайта оперативки. Базы данных. ПОЗОР!
> Совсем разучились программировать. То ли дело раньше... Возьмёшь, доставишь ещё 32
> мегабайта и всё летает...Дада, раньше было очень много ecommerce решений с нагрузкой по 600-800 запросов в секунду на ноду (с парой десятков их), баз данных по пару сотен гиг с постоянными транзакциями, innodb pool тоже наверное стоит держать "пару мегабайт", от мемкеша-мембейза вообще избавится (и пусть весь мир подождет!).
Если вы не админили ничего, где такие объемы оправданы - это не значит, что таких задач нет. А тенденция забивать кривые решения с помощью "многажелеза" появилась очень давно, но как только начинается серьезное масштабирование - оно уже не работает, при всем желании и даже огромном бюджете.
Это был ответ комментатору Щекн Итрч ниже.
А вам (samm) отвечу: тенденция забивать мегажелезом кривые решения есть, но есть и решения, которые требуют мегажелеза не в силу своей кривизны, но в результате общего повышения уровня абстракций (утрированный пример: веб-приложения на ассемблере работали бы быстрее, но лучше от этого бы не было) или специфических требований (утрированный пример: гигабайт информации требует для своего хранения гигабайт места - ничего плохого в этом нет).>>Если вы не админили ничего, где такие объемы оправданы - это не значит, что таких задач нет.
Такие конкретно аппаратные решения не админил, но прекрасно понимаю, что память - ресурс, который нужно использовать когда это оправданно. Перечитайте мой исходный комментарий (осторожно - две строки сарказма).
> Знаете... Некоторые идиоты ставят на сервера 64+ гигабайта оперативки. Базы данных. ПОЗОР!
> Совсем разучились программировать. То ли дело раньше... Возьмёшь, доставишь ещё 32
> мегабайта и всё летает...Знаете, у некоторых НАГРУЖЕНЫ сервера :)
И "64+ Гб" -- самое то :)
Вы про Интернет, ваще, слыхали? Это такое место, где бывают ну оччень посещаемый сайьы :)
Сабж кто-нибудь использует?
Стабильно. Удобно.
Дельный обзор. Стоит добавить то, что oi_148 был тестовый релиз. А 151 планируется как "стабильный". Потому долго вылизывают.
Вообще надо прекрящать писать про "требуется минимум 768 Мб ОЗУ". Чтобы хоть как то система не тормозила на zfs надо от 2ГБ.
Не знаю, у меня солярка на древнем ноуте с 512 Мб вполне шевелилась. Другое дело, что про "многозадачность" пришлось забыть))) ну и желательно выпилить порядка 50 серверных сервисов, которые на персоналке нафик не нужны.
> Не знаю, у меня солярка на древнем ноуте с 512 Мб вполне
> шевелилась. Другое дело, что про "многозадачность" пришлось забыть)))Под шевелилось вероятно имеется в виду - ползала :)
Что ж их качает из стороны в сторону то с репозиториями. То pkgsrc прикрутят, то теперь еще что-то, при этом от собственного убожества избавляться почему-то не хотят. А отсутствие компилятора в базе вообще дикость какая-то. Вот и получается, чтобы завести сеть, надо скомпилить дрова, что бы скомпилить дрова, надо скачать из репозитория компилятор. А просто так скачать его нельзя, только из-под индианы... мрак короче...
> Что ж их качает из стороны в сторону то с репозиториями.
> То pkgsrc прикрутят, то теперь еще что-то,SFE для OI появился задолго до того, как появился интерес к pkgsrc.
Одно другому не мещает и не противоречит. Пакеты pkgsrc ставятся
в /opt/ipp/pkg IIRC и другим пакетам никак не мешают. Кроме того,
там своя пакетная система, pkgsrc-ая. Иметь много источников
пакетов для Соляриса -- весьма распространенная практика.
k-freebsd уже есть, почему разработчикам нексенты не объединиться с дебиан потеснее, раз они решили на пакетной базе сквиза делать ?
Потому что они фанаты Solaris ядра (и они готовы страдать ради него), а не FreeBSD.
вообщето и имелось ввиду сделать отдельно ветку на ядре соляриса также как есть уже на ядре фрибсд
> вообщето и имелось ввиду сделать отдельно ветку на ядре соляриса также как
> есть уже на ядре фрибсдСкорее всего, соляру в дебиан не пустят - она не соответствует жестким дебиановским требованиям к свободе ПО.
> вообщето и имелось ввиду сделать отдельно ветку на ядре соляриса также как
> есть уже на ядре фрибсдkFreeBSD основан на GNU libc. Она никому не нужна в IllumOS/Nexenta.
К тому же, Nexenta зарабатывает деньги, это не волонтерский проект.
Зачем им терять время на терки с разработчиками Debian?
да уж конечно!
куда там бедолагам из рэдхэта, сюзе да и самого оракла с их коммерческими линухами.
Никто не страдает. Они на ядре solaris + zfs зарабатывают... Это может вызвать страдания разве что только у тех у кого зарабатывать на открытых технологиях не получается.
Да ну че смеяться. Кто у них это купит? Перспективы проекта постоянно под вопросом, то ли исходный код ядра соляриса будет доступен, то ли нет. Сроки поддержки? Команда? SLA? Если проект успешный, то обычно всегда есть раздел на сайте "Наши клиенты" и там что-то типа Dell, IBM и т.д. Нет, этот Nexenta just for fun.
> Да ну че смеяться. Кто у них это купит? Перспективы проекта постоянно
> под вопросом, то ли исходный код ядра соляриса будет доступен, то
> ли нет. Сроки поддержки? Команда? SLA? Если проект успешный, то обычно
> всегда есть раздел на сайте "Наши клиенты" и там что-то типа
> Dell, IBM и т.д. Нет, этот Nexenta just for fun.На мой взгляд даже если Oracle перестанет выкладывать исходники,
IllumOS имеет перспектив не меньше, чем все BSD.
Наработок там более чем достаточно.
Это при том что там кусок ядра закрытый? О, а какие были перспективы у проприетарных юниксов. Только что-то они почти все слохли, а? :)
> На мой взгляд даже если Oracle перестанет выкладывать исходники,
> IllumOS имеет перспектив не меньше, чем все BSD.
> Наработок там более чем достаточно.Имхо, пока не понятно. Все зависит, будет ли у них крупный спонсор.
>> На мой взгляд даже если Oracle перестанет выкладывать исходники,
>> IllumOS имеет перспектив не меньше, чем все BSD.
>> Наработок там более чем достаточно.
> Имхо, пока не понятно. Все зависит, будет ли у них крупный
> спонсор.Ну, один спонсор уже есть. Собственно Nexenta.
> Потому что они фанаты Solaris ядра (и они готовы страдать ради него),
> а не FreeBSD.Потому, что Nexenta довольно платная вообще-то.
>> Потому что они фанаты Solaris ядра (и они готовы страдать ради него),
>> а не FreeBSD.
> Потому, что Nexenta довольно платная вообще-то.http://www.nexentastor.org/projects/site/wiki/CommunityEdition
СЕ имеет ограничения на объем хранилища.
Free for up to 18 TB of overall raw storage capacity (i.e. sum of all ("raw") disks sizes, excepting logs, caches and spares)Как и Enterprise, впрочем :)
http://www.nexenta.com/corp/component/virtuemart/?page=shop....
http://www.nexenta.com/corp/component/virtuemart/?page=shop....
Порт ZFS под FreeBSD местами по-прежнему оставляет желать лучшего по части стабильности и быстродействия.Выражаясь простым языком: мотоцикл более быстр и надежен, чем велосипед с прикрученным проволокой бензиновым моторчиком.
Можно пример насчет стабильности? Гоняю stable-8 c 8T хранилкой без всяких проблем.
На семёрке уже гонялось без каких либо проблем, задуматься на 7 зфс любил, но гонялось без проблем, да и называть портом официальный модуль ядра, который пилят не кто-то там, а такие люди как Pawel Jakub Dawidek, Мартин Мутушка, и иже с ними - как-то язык не поворачивается.
А учитывая обновление пулов на лету ( обновление версий со всеми добавленными плюшками ), при обновлении системы, либо модуля ядра, возможность на лету менять размеры пулов, если в 1 маловато места, давая ему от главного - так вообще сказка.Да и надёжность - при нагрузках, вылетах питания, и тд - замечено неизлечимых багов небыло, собираем в хранилища райды 5, 50, и тд на серваках, работают - только дым.
> На семёрке уже гонялось без каких либо проблемСемёрка — не та версия ОС, на которой ZFS годна к продакшену. Только на 8'ке она официально годна.
> Семёрка — не та версия ОС, на которой ZFS годна к продакшену.
> Только на 8'ке она официально годна.Я в курсе, но это не отменяло возможности готовить зфс на 7 по вкусу. И оно работало, просто в 8 ветке ей больше внимания уделять стали, и сильнее пилить модуль совмещая как можно теснее с ядром, и убирая лишние ошибки в коде блокировок.
золотые слова.
> Порт ZFS под FreeBSD местами по-прежнему оставляет желать лучшего по части стабильности
> и быстродействия.
> Выражаясь простым языком: мотоцикл более быстр и надежен, чем велосипед с прикрученным
> проволокой бензиновым моторчиком.Не троллите.
Приведите uname -a, список железа, проблемы.
>> Порт ZFS под FreeBSD местами по-прежнему оставляет желать лучшего по части стабильности
>> и быстродействия.
>> Выражаясь простым языком: мотоцикл более быстр и надежен, чем велосипед с прикрученным
>> проволокой бензиновым моторчиком.
> Не троллите.
> Приведите uname -a, список железа, проблемы.Во Фре нет afd, прежде всего, который может standby шпинделя в пул вводить.
>>> Порт ZFS под FreeBSD местами по-прежнему оставляет желать лучшего по части стабильности
>>> и быстродействия.
>>> Выражаясь простым языком: мотоцикл более быстр и надежен, чем велосипед с прикрученным
>>> проволокой бензиновым моторчиком.
>> Не троллите.
>> Приведите uname -a, список железа, проблемы.
> Во Фре нет afd, прежде всего, который может standby шпинделя в пул
> вводить.Не троллите.
/dev/afd*
ATAPI floppy drive device nodes
>/dev/afd*
>ATAPI floppy drive device nodesОхлол. А теперь посмотрите, что такое afd в соляре.
>>/dev/afd*
>>ATAPI floppy drive device nodes
> Охлол. А теперь посмотрите, что такое afd в соляре.И? Что есть "стендбай шпинделя в пул вводить"? )
А я вот с ним согласен. У меня ZFS пул за год помер один раз на 7.x и один раз на 8.x, причём на разных винтах, чего никогда не было с, например, UFS или NTFS. Причём ничего толком по восстановлению не найдёшь, разве что спецификацию на ФС.
> NTFS. Причём ничего толком по восстановлению не найдёшь, разве что спецификацию
> на ФС.На лисяре была статейка по восстановлению. Довольно жесткая - с ручным разбором дампов после чтения мана.
Подробности, подробности в студию!
Ибо К.О. говорит, что если бы всё было бы так плохо, то платная ZFS просто бы не продавалась бы.
>Ибо К.О. говорит, что если бы всё было бы так плохо, то платная ZFS просто бы не продавалась бы.К.О. намекает, что это проблемы бесплатной ZFS на бесплатной FreeBSD, и платной ZFS на платной Solaris/Nexenta они не касаются.
> Порт ZFS под FreeBSD местами по-прежнему оставляет желать лучшего по части стабильности
> и быстродействия.
> Выражаясь простым языком: мотоцикл более быстр и надежен, чем велосипед с прикрученным
> проволокой бензиновым моторчиком.Говоря простым языком - ZFS точилось под ядро Солярис, под ним же и разрабатывалось. Надо ли удивляться, что харлей с Кадиллаковским движком не едет?
> Говоря простым языком - ZFS точилось под ядро Солярис, под ним же
> и разрабатывалось. Надо ли удивляться, что харлей с Кадиллаковским движком не
> едет?Дада, когда заканчиваются аргументы - начинаются автомобильные "онологии". Код ZFS ни подо что не затачивался, а изначально писался в достаточно портируемом виде. Так же как и код dtrace, например. По вашей логике и код XFS кроме ирикса нигде не должен работать, как и jfs только на аиксах, например. Глупость сказали, вот и все.
А кто-нибуть в курсе, поддержка VAAI это фича Nexenta или в OpenIndiana oi_151 то же появится?