Опубликован релиз Proxmox Virtual Environment 7.4, специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таких продуктов, как VMware vSphere, Microsoft Hyper-V и Citrix Hypervisor. Размер установочного iso-образа 1.1 ГБ...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58856
Темная тема, срочно обновляться
Смена версии ceph? Не, опеннетовским экспертам понятно только про тему.Обновляться я бы правда именно по этой причине не рискнул. Хотя... те кто пользуют ЭТО привыкли страдать. Страдание очищает.
3 локальных кластера, 1 распределённый. Около 40 нод, хранилки на Солярке и на TrueNAS. Всё работает, просто работает, без бубна и заклинаний. Укажи мне путь к страданию, о великий гуру?
Заняться чем-то помимо майнинга и отмывания денег не пробовал?Хотя, действительно, зачем же ж...
P.S. расскажи, как в твоей чудо-системе смигрировать виртуалку в этот распределенный из нераспределенного, если вдруг, внезапно, выяснилось что это что-то критичное (откуда у тебя.. ну вдруг)
Пальцем в небо попали, гражданин провокатор. Это кластеры разных клиентов, никак не связанных между собой, ну только админ общий.
Если вдруг возникнет такая задача -
zfs send имя-снапшота | ssh host zfs receive имя-номер-виртуалки
на хранилке источника. А потом файл описания виртуалки скопипастить из кластера-источника и поправить имя пула хранения диска
Огромный плюс Proxmox - текстовые конфиги, которые можно править на летуНе, не гуру - просто балабол местечковый ;)
> Если вдруг возникнет такая задача -
> zfs send имя-снапшота | ssh host zfs receive имя-номер-виртуалкикруто. И пока оно копируется - виртуалка спокойно полежит.
А если у тебя там не zfs а к примеру lvm как местные эксперты насоветовали?> Огромный плюс Proxmox - текстовые конфиги, которые можно править на лету
да просто зашибись вообще.
Если что - в нормальных коммерческих системах виртуализации (ни на что не намекаю, но это vmware) конфиги тоже в общем-то текстовые. Но правил я их руками последний раз восемь лет назад для очень специфического эксперимента.
А перенос виртуалки в другой кластер делается вот так: move-vm 'name' -Destination 'name'
Разумеется, она при этом ничего даже и не заметит.
>> Если вдруг возникнет такая задача -
>> zfs send имя-снапшота | ssh host zfs receive имя-номер-виртуалки
>круто. И пока оно копируется - виртуалка спокойно полежит.Ну да, нет проблем. У меня почти все виртуалки обязаны работать 12 часов в сутки, а остальное время имеют право лежать. И да, если мы такое делаем, значит либо с виртуалкой что-то не так и она всяко уже лежит, либо нам надо копию для экспериментов и нас вполне устроит снапшот живой машины, которую не надо стопать для этого.
>А если у тебя там не zfs а к примеру lvm как местные эксперты насоветовали?
Что там советуют любители "европэйсих ценностей" и использования интерфейса вывода для ввода - мне не интересно. Я гей-порно не смотрю ;)
>коммерческих системах виртуализации
Вот сразу нахер с пляжа. У меня задача решить проблемы клиента юридически чисто с максимальной эффективностью за минимальные деньги. Понятие "стоимость софта" в решении этой задачки лишнее.
Поправить текстовый конфиг зачастую гораздо быстрее, чем ползать по веб-морде и искать нужные кнопочки-галочки. Благо у веб-морды прокса легко доступно окно консоли, если уж нет линукса под рукой
>А перенос виртуалки в другой кластер делается вот так: move-vm 'name' -Destination 'name'
>Разумеется, она при этом ничего даже и не заметит.И, разумеется, трастовые отношения между кластерами вмвари настроены заранее? ;) Мы же обсуждаем перенос виртуалки между разными кластерами.
В пределах одного кластера Proxmox, разумеется, умеет live migration и оно прекрасно работает. В том случае, если процессоры у нод одинаковые. Но live migration между Intel и AMD, например, не умеет и нежно облизываемая vmware, причём от слова "совсем"
Да, я не знаю, как в проксе сделать межкластерный траст, скорее всего - никак. Но за много лет использования прокса (с 3 версии) мне это понадобилось 2 раза и оба раза вариант с zfs send-receive меня полностью устроил
> Да, я не знаю, как в проксе сделать межкластерный траст, скорее всего - никак.qm help remote-migrate
и да, не кормите тролля 8)
Диванный эксперт подъехал. Что же вмваря (не к обеду называть этих беглых из страны "бизнесменов", которые, как известно, "слово держат") не сделает то, что в PVE есть уже годами - хотя бы тот же файрволл на каждую ВМ?
э.... простите, на...я мне файрвол на уровне бриджа? Вмварь не занимается маршрутизацией и никакого другого места для файрвола там нет. (а еще бывает sr-iov где и бриджа-то нет)(я, конечно, хрен знает что они там на...евертили в своей sdn, оно стоит столько что как-то прошло мимо меня, даже подержаться на превью не дали)
Это система - виртуализации. Для остального есть другие продукты. Я вполне был счастлив своей палоальтой в качестве файрвола.
сделали б они LTS лет на 7-10 ...
100% поддерживаю
Так он у них есть. Но есть нюанс... за деньги. А ты думал - они святымдухом питаются и за все хорошее против всего плохого тебе подогнали систему виртуализации для мышекликеров?
и эта
за деньги у них тоже нет если чо,
вот бред писать можно и бесплатно .
В смысле? Плати 150 евро за процессорное ведро - и будет тебе stable repository. А нет денег - ну так работай бетатестером, чего уж там.
Неплохая система виртуализации, активно развивающаяся, с достаточно адекватным сообществом, хорошей документацией и кучей рецептов на все случаи жизни. Это мы используем. Удачи проекту в развитии.
В китае - нет. В китае не брезгуют и за вмварь заплатить, если на самом деле надо.А вот у тебя уже не получится - нет дырочки для запихивания твоих юаней. Пользуйся скрепным импортозамещенным ничего.
ну там у астры и у альта есть какие то самодельные перделки на квм.
что там внутри хз - они платные
> что там внутри хз - они платныену я предположил, что, но ищи ответ в удаленных - опеннет место для троллинга а не для разговора на технические темы
ггг а бихайв не хотите? vstack с ним регулярно на хабре пиарится
Брр, нет уж. Чур меня, чур. Умерла так умерла.vstack это нечто настолько законченное в своем ан...нетстве что тут даже близко без химзащиты подходить не стоит.
И да, напомните, как у бихайва с лайвмигрейшн.
> как у бихайва с лайвмигрейшн.встак в прошлом году грозились запилить
но пока молчат
шо - опять? Я уже лет пять самое малое слышу что все почти уже готово, в ядре все для этого есть, надо только... но видимо только начать и кончить - потому как до сих пор ни у кого не работает.Мать-мать-мать - у _вбокса_ есть аналог - сколько там чудо технологии - 10 лет, пятнадцать?
Ну с другой стороны - немодные видимо, неинтересно никому. От тех же ниасиляторов ниасиливших ни нормальную загрузку виртуалки без чудовищного костылингопердолинга, ни поддержку банальнейшего ide контроллера...
(причем для второго им даже патч на блюдечке приносили - но нет, не так подано было)
>даже патч на блюдечке приносилиу меня от слов патч для иде контроллера для фрибсд вьетнамские флешбэки 20 летней давности начинаются
не надо так ☺
>>даже патч на блюдечке приносили
> у меня от слов патч для иде контроллера для фрибсд вьетнамские флешбэкида не для фрилсде, мать, а для виртуальной машины - чем проще виртуализированный драйвер тем надежнее и лучше, для остального существуют паравиртуальные.
И уж не фре бы задирать нос - вот как раз какое-нибудь дремучее легаси, которое уже невозможно запустить внутри нормальной системы - вполне было бы ее полем применения, и уже неважно что она не умеет в миграцию и загружается с ручного стартера (тоже конечно восхитительная особенность).
Но нет. Виртуалка пережившая за двадцать лет и вмварьский сервер, и esxi, и вбокс, и успешно запускающаяся без малейших проблем сегодня в линуксном kvm - во фре не работает и не будет никогда.
> не надо так ☺
да, не надо. Плюнуть и растереть. Помер максим да и хрен в общем-то с ним.
При импорте VM надо создать VM на Proxmox, запомнить имя файла вирт.диска, удалить и подложить вместо него вирт.диск от импортируемой.
Чтобы повесить vlan на интерфейсы, надо юзать ansible.
RAID на ZFS (вместо mdraid), не имеющей fsck, чтобы если грохнулось, то всерьез и надолго.Отличные рецепты, не поспоришь.
mdraid c write hole тоже, знаешь ли, так себе решение.А потом ты поверх него развернешь еще lvm, потому что в снапшоты он не умеет, да? И как у тебя с fsck для lvm?
P.S. и вроде пятая версия умела в импорт ova. Ничего руками создавать было не надо. Седьмая что - разучилась?
Я тоже так импортил диск один раз по незнанию)), но если почитать доку, то для этого есть команды и диски нормально конвертируются и подключаются к виртуалке без этой рукопашки с подменой диска.
Тут командой, там ансиблей, здесь прямое редактирование конфигов. Именно так я себе и представлял готовое законченное решение для замены vShpere и Hyper-V.
Ну да, вмваря и гиперв делают всё прямо, без сбоев и гемора, вот прямо волшебной палочкой?
> Ну да, вмваря и гиперв делают всё прямо, без сбоев и гемора,
> вот прямо волшебной палочкой?импорт ova - вполне себе. Подключение существующих дисков к любой существующей виртуалке - без ручного редактирования конфигов - тоже.
Инвертируй:
Импортируй qcow2 в esxi без cli, без заливки по ssh и без 10 кликов (+/-20 мизкликов) в морде к esxi?
И прикинь - qcow2 тоже открытый формат.
прости а нахрена мне твой пердолинг ради пердолинга?У чувака не работает банальнейшее - импорт вм. В гуйне которая по идее такие вот банальные вещи и призвана делать если не удобными то хоть простыми.
У меня - работает. qcow твой мне при этом нахрен не нужен. Это никому кроме альтернативно-одаренных нахрен не сдавшийся формат дисковых образов, понимаемый целой одной (ок, полутора целыми) системой. А не формат образа вм целиком.
Ты дурочку-то не включай. Тебе специально опустили лишнее - ova это просто tar'ник, в который напиханы описатель (на базе оверидиотоинжиниреновых спек) и когда-то проприетарный (и кривой) vmdk, который решили опубликовать под lgpl только в 2009 в рамках созданного междусобойчика dmtf.
Инвертируй снова - запихай backup vm из proxmox парой кликов в свой сферический vsphere. Не можешь? Так и не зуди.
Иди дальше страдай своим перманентным пердолингом ограничивающими лицензиями, с guid-логами по ошибками безо всякого документирования и без возможности что-либо оперативно исправить в мордах к esxi.
понимаешь, дурашка - ova - стандарт. И понимается всеми - КРОМЕ твоего васянского софта который никем нигде и никогда (помимо гордых васянов с локалхостом) не использует и не будет.То что авторы проксы не осилили в стандарты - это проблема проксы, а не остального мира. Поэтому пердолиться будешь ты. Потому что если ты принесешь мне вместо дистрибутива какой-то там "бэкап" - впрочем, у нас в лаптях и не пускают. А если тебе велят поставить вон то - то твои оправдания что у тебя патроны не той системы никто слушать и не будет.
То что у тебя нельзя даже ткнуть в конфигурашке "подключи мне вот этот файл с хранилки диском к вон той вм и мне неинтересно твое мнение что он подключен еще к двум, как и искать на каком хосте и в каком месте этот конфиг сегодня лежит" и надо лезть в конфиги - тоже проблема проксы. Я уж боюсь представить что будет если вместо файла я захочу отдать напрямую с хранилки что-нибудь.
В конфиг на хосте esxi мне лазить никогда не понадобится. Я вообще хз где от него учетку взять. У меня ж не васянская поделка на бесплатной лицензии (с игнорированием что с ней вообще-то не все можно делать и очень интересных обязательств которых васян не читает прежде чем жать ок).
Вытащи себя из лошков уже, за волосы - tar стандартизирован с 1998 в POSIX.
Распаковать tar и выполнить importovf давно можно в pve.
И мне нельзя повелеть - это у таких как ты принято, чуть что "слушаюсь барин" - иди бекап разворачивай от proxmox, через гуйнину для esxi.
А у меня TCO просчитано и ниипёт.
Ну а приведённые тобой "кейсы" - это просто говнина какая-то для всяких ССЗБ, типа тебя. У меня за такие выверты - подрубать один накопитель в несколько vm - ты сразу был бы послан в известном направлении.
До тебя, неопещерного видимо не доходит, что в кластере, пара нод могут быть предназначены исключительно для администрирования, там тебе и web-морда и терминал для управления всем кластером.
RTFM
RTFM, vlan на интерфейсы прям из web-морды вписывается
RTFM, ZFS не нужен fsck
не спорьте с Псевдоумнусом) он знает свою зоопарк лучше ... пусть использует то что хочет
> ZFS не нужен fsckЭто пока оно не развалилось. Хотя соглашусь: когда развалилось - тоже уже не нужен, ничего оттуда не вытащищь.
Если развалилось - то либо подохла основная часть накопителей, либо сломался мозг того, кто потёр данные. В остальных случаях ZFS можно вернуть в работу - RTFM. А для тех кто не может в RTFM - создан всякий виндузячий софт типа klennet zfs или diskinternals raid recovery.
Использую, доволен, но приходится ставить на чистый Дебиан, тк родной граф. инсталятор не понимает встроенную в плату видюху и из-за 8Gb ОЗУ ставлю на программный RAID1 вместо ZFS, которого тоже нет в инсталяторе.
А что не так с ZFS-рэйдом?
Это тот, который требует 2 гб памяти на каждый терабайт стораджа чтобы работать относительно нормально? Действительно, больше же нечем занять оперативку.
Гораздо больше. Под нагрузкой приходится очень сильно подкручивать параметры. Иначе всё дохнет.
А дедубликацию отключить не пробовали ? При отключенный дедубликацию на 8-10 гиг ОЗУ ZFS уже в принципе работает.Конечно при условии что рэйд не на 100 тб,тогда памяти побольше потребуется.
Всего 4 диска было, так что около 70. Да, занять память кроме как рейдом действительно больше нечем, о чём и речь.
Кэширование нинуна, нинуна, нинуна!Память нонеча дорога а пользователи - еще подождут.
Ну и ресурс накопителей надо ж убить побыстрее, а то на новые бюджет не выделят.
Зойчем двойное кеширование (да ещё и с системными буферами в случае ZFS не дружащее) на уровне доступа к NAS/SAN, если виртуалки сами себе кешируют то, что им нужно?
> Зойчем двойное кеширование (да ещё и с системными буферами в случае ZFS
> не дружащее) на уровне доступа к NAS/SAN, если виртуалки сами себе
> кешируют то, что им нужно?затем что диск читается не теми кусками которые нужны виртуалке - потому что это был бы бесконечный трэшинг. Она ж ничего не знает ни о том что диск виртуальный и на самом деле размазан по десятку, ни что параллельно другая виртуалка читает смежные блоки.
Поэтому block reordering, prefetch, а иногда и fair-queue и рейтлимитеры.
В общем-то ты всегда можешь выключить префетч у zfs и сам убедиться, что начинается форменный п-ц. (потому что читать он все равно будет как минимум блоками, но, поскольку доктор сказал в морг - почитанное немедленно роняется на пол и при следующем запросе читается заново)
Смежные блоки - это префетч. Толку от него в последнее время реально как от козла молока, большинство чтений либо большими последовательными кусками, либо мелкое рандомное.
ну и как ты узнаешь извне виртуалки - это вот последовательный кусок читают и сейчас придут за продолжением, или один блок? Поэтому и префетч. Диски без перепозиционирования - быстрые, флэши в пределах страницы вообще мгновенные, поэтому лучше почитать лишнего чем потом заново инициировать операцию.И так оно на всех уровнях - внутри самого накопителя тоже те же технологии.
Я ж говорю, есть прекрасный способ убедиться, в zfs он выключается. При этом она разумеется продолжает читать большими кусками, но хозяин велел без префетч - ок, старательно бросает все лишнее на пол и при следующем запросе еще раз читает то же самое.
Результат, если сможешь его померять и отобразить читаемо - тебя приятно удивит.
Не надо это извне узнавать. Виртуалка свой префетч имеет, о котором знает, и о том, что ей из этого куска реально нужно - никому не скажет, никому и не надо.
То, что ZFS без него нормально не живёт - ну, проблемы индейцев, вот это всё.
> Всего 4 диска было, так что около 70. Да, занять память кроме
> как рейдом действительно больше нечем, о чём и речь.А слово кэш не слыхал ? Вон у меня ноутбук-14 гб чистой памяти,на кэш уходит 8гб,а у ZFS есть проблема (не знаю насколько актуальная) у нее собственный кэш,не интегрированный с VFS ядра.Из-за этого и жручесть Озу у ZFS//
у ведра нет никакой интеграции кэша с vfs. Вот у zfs - она есть. А у ведра твоего обычный buffer cache, не отличающий что нужно от того что не нужно кэшировать никак. Из-за этого никакой дополнительной жручести нет - наоборот, в дефолтных настройках буферкэш занял бы почти всю доступную память, а zfs прижата 50% барьером и часть памяти (если конечно она свободна) просто пропадает зря.Проблемы жручести зфс как обычно - выдуманы людьми слышавшими звон перепетый рабиновичем.
В целом в варианте проксмоксиного наиболее вероятного применения - там вообще нет ТАКОЙ проблемы.
Но вот стоит ли в принципе связываться с zol в ее нынешнем сумеречном состоянии - вопрос сложный. Вполне вероятно что лучше вообще плюнуть и оставить все на lvm volumes. хотя, неумение этой штуки в thin вероятно все испортит.Ставьте ovirt короче, не выпендривайтесь. Больше на этом базаре продавцов все равно нет.
> связываться с zol в ее нынешнем сумеречном состоянии - вопрос сложный.Это по поводу лицухи или технически?
>> связываться с zol в ее нынешнем сумеречном состоянии - вопрос сложный.
> Это по поводу лицухи или технически?Технически. Когда лидер проекта на найденый с точностью до конкретного куска кода и подтвержденный баг отвечает что "нет ресурсов" им заниматься. Касался, кстати, именно zvol. (Через пару лет все же исправили - но осадочек-то...)
> Технически.Да, согласен... то же самое как с musl, сколько было тыкания носом в РФЦ что DNS должен поддерживать TCP, пока народ не начал сваливать с Alpine, теперь "о создатель", проснулся... но осадок остается.
>Вполне вероятно что лучше вообще плюнуть и оставить все на lvm volumes.
>хотя, неумение этой штуки в thin вероятно все испортит.А что именно не умеет thin? И LVM-thin и Zvol нормально под сабжем работают.
> А что именно не умеет thin? И LVM-thin и Zvol нормально под
> сабжем работают.они уже научились устанавливаться на thin? Раньше его требовалось создавать вручную, а поскольку мало кто понимает как он работает и где грабли - лучше уж было плюнуть и остаться на zfs (на которую с пятой версии научились ставиться самостоятельно и автоматически)
>у ведра нет никакой интеграции кэша с vfs.Странно,я читал что с 4 версии ядра кое какие механизм есть.Порывшись в инете а именно https://russianblogs.com/article/89331674217/
Цитирую оттуда >>>
Как видно из рисунка, в Linux конкретные файловые системы, такие как ext2 / ext3, jfs, ntfs и т. Д., Отвечают за обмен данными между файловым кешем и устройствами хранения, а виртуальная файловая система VFS, расположенная на определенном файловая система отвечает за обмен данными между приложением и файловым кешем через интерфейсы чтения / записи, а система управления памятью отвечает за выделение и восстановление файлового кеша, а система управления виртуальной памятью (VMM) позволяет карте памяти использоваться между приложением и файловым кешем Обмен данными. Можно видеть, что в системе Linux кэш файлов является концентратором связи между системой управления памятью, файловой системой и прикладной программой
> Это тот, который требует 2 гб памяти на каждый терабайт стораджаСлышал звон, но не знает где он...
ЗФС нужно много памяти если используется дедупликация, а без нее на двух гигах памяти можешь навесить десятки терабайт и все прекрасно будет работать
Ну во-первых толку от неё без дедупликации, а, во-вторых, ты грязный врунишка.
> Ну во-первых толку от неё без дедупликацииДа ну !?
А в нетфликсе то и не слышали твоего "гениального" мнения...
ЗФС про надежность, а не про экономию на копейках> , а, во-вторых, ты грязный врунишка.
Если у тебя руки растут не как у всех людей, - то это твоя проблема
>> Ну во-первых толку от неё без дедупликации
> Да ну !?ну да
> А в нетфликсе то и не слышали твоего "гениального" мнения...а в нетфликсе нет zfs. вообще.
> ЗФС про надежность, а не про экономию на копейкахглядя на стойки нетапп (да, внутри это клон zfs) - ничего так себе копейки.
Но да, бывают приключения. Но при цене этих деталек - лучше быть повнимательней и поаккуратней, но новую полку купить как-нибудь не в этом году.Но разница как раз в том что у нетапы - работает, и достаточно предсказуемо. А у выкинутой на помойку реализации openzfs - не очень (технология в момент выкидыша была в зачаточном состоянии, нетапа справилась а эти затобесплатные - как обычно).
> а в нетфликсе нет zfs. вообще.Не правда. Сама загрузка, конфиги, логи (система одним словом) сидит на ЗФС, а сам контент для стрима на UFS2
> глядя на стойки нетапп (да, внутри это клон zfs) - ничего так себе копейки.
А причем здесь это? Я говорю про дедупликацию. Есть область применения где это очень сокращает обьем носителей и дедупликация оправдана, но если контент зашифрованное файло, медиа и прочий наиблее встречающися контент, то смысла от дедупликации от вкладывания в гигансткое количество памяти и материнок которые поддержат - нет
> нетапы - работает, и достаточно предсказуемо. А у выкинутой на помойку реализации openzfs - не очень
нетапы основаны на Фряхе, и с недавнего времени Фряха решила обьеденится с ОпенЗФС т.к. там движуха значительно активней и совместимость тоже не на последнем месте
>> глядя на стойки нетапп (да, внутри это клон zfs) - ничего так себе копейки.
> А причем здесь это? Я говорю про дедупликацию. Есть область применения гдену вот она в тех стойках - включена. Иначе б мы разорились давно. Да и не влезет оно просто - там где-то 1:3 получается в среднем по больнице. Еще два раз по столько полок в цод не поместится.
Да, за потреблением памяти надо следить - само оно иногда может таки встать колом. Но чаще всего справляется, а потери нервов по мнению бизнеса вполне оправдывают экономию.
> это очень сокращает обьем носителей и дедупликация оправдана, но если контент
> зашифрованное файло, медиа и прочий наиблее встречающися контент, то смысла отоно поверх сжатия идет - так что считай что всегда зашифрованное. не спрашивай меня, что там такое - подозреваю, стопиццот копий одних и тех же сканов, например, принадлежащих разным сервисам.
> нетапы основаны на Фряхе, и с недавнего времени Фряха решила обьеденится с
ни б-же мой. Это ты с прямым уг... с freenas перепутал.
Нетапа когда-то очень давно использовала код от фри, но они давным давно ушли в свою сторону и обратно не синхронизируются - т.е. там не openzfs а что-то давно уже совершенно отдельное, и судя по их недавним попыткам кое-что отдать в опенсорс - разошлись они где-то в районе когда все примерно соответствовали солярисному образцу, общего у них теперь считай нихрена (openzfs теперь тоже вовсе не похожа на ту zfs что еще была совместима с оракловой). Т.е. общий предок там жил во времена freebsd8.
> ОпенЗФС т.к. там движуха значительно активней и совместимость тоже не на
> последнем местеесли бы...
Просто кому-то надоело кормить разработчиков.
> если бы...
> Просто кому-то надоело кормить разработчиков.Лютая правда...
Нетфликс, кек. Ещё можно вспомнить, что у гугла ext2 "для надёжности".
> Нетфликс, кек. Ещё можно вспомнить, что у гугла ext2 "для надёжности".c разморозочкой. в 2009м они перешли на ext4/nojournal
да, для надежности в том числе - так как умела терять данные ext3 2003-2007 примерно года издания - никому больше не удавалось. (журнал без контроля целостности)
Но в первую очередь из-за ее дичайших тормозов.
У ext4/nojournal производительность ext2, кстати. На практике вообще не юзабельно. А у гугла вроде свои костыли для контроля целостности и всего прочего, так что могут себе позволить.
> У ext4/nojournal производительность ext2, кстати. На практике вообще не юзабельно.пользуюсь везде кроме тяп-ляп установленного по шаблону для либо одноразовых экспериментов, либо чужих проектов где запросили "стандартное". Потому что на современном железе журнал не имеет ни малейшего смысла.
А там где он мог бы иметь какой-то смысл, там не ext4.Что я делаю не так? Производительность от убирания лишней двойной записи метаданных только вырастет.
> гугла вроде свои костыли для контроля целостности и всего прочего, так
Гуглю ее нет смысла контролировать. От того что в твоем мега-творении на ютубе выпадет целый один битик - никто не помрет и даже не узнает об этом. А вот ошибка его чтения с паниками или даже пусть просто сбоями не ожидающего такой подставы софта - это плохо. И что с этим делать - совершенно непонятно (то есть пользы от знания что битик выпал нам никакой).
Ценные данные он, разумеется, в таком виде не хранит. Но твои видео для него никакой ценности не имеют - пойдет что-то не так - сам и перезальешь.
Время доступа возрастает на порядки, пиковая пропускная способность падает в разы. Вот, что не так ты делаешь. Использование может быть оправдано, когда где-то на другом уровне кто-то позаботится о сохранности данных, что в стандартной ситуации совсем не так. Надёжный способ повысить производительность это journal_data_writeback, только, опять же, если прилетит паника или обесточивание, в открытых на запись файлах окажется мусор с весьма высокой вероятностью.
> Время доступа возрастает на порядки, пиковая пропускная способность падает в разы.а мужики-то и не знали.
Скажи, вот какие бредовые предположения об устройстве фс вообще навели тебя на предположение о таком бреде? (Я понимаю что проверять их тебе в голову вообще не приходило, но что, чорт подери, должно быть у человека в голове чтоб вообще нафантазировать такую чушь?)> ситуации совсем не так. Надёжный способ повысить производительность это journal_data_writeback,
тооочно! Если мы данные два раза на диск запишем вместо одного - мы надежно ж повысим производительность!
Ну, во что ты там истово веришь тоже не имеет никакого значения. Я полноценно бенчил и профилировал под нагрузкой, например. А ты?
> Ну, во что ты там истово веришь тоже не имеет никакого значения.я не верую, я знаю как это работает. И могу делать вполне обоснованные выводы из этих знаний.
> Я полноценно бенчил и профилировал под нагрузкой, например. А ты?
а я убедился что у меня нет описываемых тобой чудес и, поскольку результат вполне совпадал с теоретическим - дальше рыть не стал.
А что ты там профилировал-профилировал да не выпрофилировал - это у тебя надо спросить. Потому что когда результат не совпадает с тем что быть должно по техническим критериям - например, от 2x write multiplication внезапно у тебя что-то там "ускорилось" - нормальный инженер идет разбираться что же он налажал в постановке эксперимента и как такое могло вообще получиться.
Но ты предпочел шаманские пляски. И святую веру в собственную непогрешимость, даже когда наблюдается явное противоречие законам физики.
Ну, никаких противоречий нет, ведь можно посмотреть как и для чего журнал используется и почему быстрее в итоге. А то ещё окажется, что это у тебя были лажовые непрофессиональные измерения, но раз они совпадали с твоими фантазиями, то ты и удовлетворился ими.
Ну же, я жду откровений.Ты же посмотрел и сейчас мне расскажешь, как синхронная запись данных в журнал с перезаписью потом из журнала невиданно что-то у тебя ускоряет.
P.S. слушайте, а вот это вот все местное стадо - это правда такие только в рф и остались, или просто этот сайт собирает ярких представителей а в целом по палате все же больше вменяемых?
Хотя... судя по ставшим ежедневными пожарам, не говоря уж о взломах инфраструктур, все так и есть.
Вы бредите.
Нет у ЗФС такого требования.
А при желании его можно вообще на минимум потребления ОЗУ накрутить.
Запускал ZFS на 256МБ ОЗУ, и всё работало отлично.
Какая нагрузка?
согласен ) даже на fresh tomato zfs завезли и работает)
Он же тебе написал - в окошкоменюшке нет.
(потому что он ставит поверх дерьмиана, в котором действительно нет, а родной графический инсталлятор ну ниасиливает у него чего-то)
8Гб памяти с 2 виртуалками становится прямо впритык 80-90%, плюс ZFS может начать ее жрать непредсказуемо, а тк Проксмокс по дефолту своп не уважает совсем, все заканчивается крэшем. С программным рэйдом и свопом на подстраховке проблем таких нет вообще, память стабильно на 70%.
> 8Гб памяти с 2 виртуалками становится прямо впритык 85-90%, плюс ZFS может
> начать ее жрать непредсказуемоПредсказуемо. Если что - я занимаюсь предсказаниями, и недорого. Но учти что предсказания не ведут к счастью.
> Но учти что предсказания не ведут к счастью.Но дают надежду :)
> плюс ZFS может начать ее жрать непредсказуемоЧитайте про zfs_arc_max
и как это засунуть в /etc/modprobe.d/zfs.conf
>> плюс ZFS может начать ее жрать непредсказуемо
> Читайте про zfs_arc_maxтам все наврано. В смысле, она будет в какие-то моменты жрать (много!) больше чем то что ты туда напишешь (потому что там только часть arc).
И max это именно максимум - т.е. больше arc у тебя не вырастет (в ущерб производительности) но это вовсе не означает что он займет именно столько.Т.е. не надо трогать эту переменную пока ничего не упало.
>8Гб памяти с 2 виртуалкамиЧто такое две виртуалки? Это какая-то новая единица в системе СИ? В какой палате мер и весов можно глянуть на эталон?
У меня простой вопрос:
Есть iSCSI SAN. SAN, не NAS!
Есть на нём ваш любимый ZFS RAID.
Как мне его подключить к полсотне хост-нод?
В VMWare с VMFS всё просто. Один VMFS на всех землекопов.
В XenServer LVMoISCSI - не сахар, но прекрасно работает.
С вашим счастьем-то что делать? Городить отдельные ноды с NFS?
ну ага, давайте блок дивайсы поверх нфс раздавать. Я такое даже периодически пользую - для миграций между цодами у нас оно, поскольку кросс-DC fc нам не светит, да и не больно-то и хотелось бы.Тот еще тормоз.
До сих пор Ceph as sdn. Как грится, тамада хороший и конкурсы интересные. Особенно интересными они станут, когда всё это развалится. А без sdn я аще не понимаю, что подвигает людей работать бесплатным бета-тестером вместо использования старого, доброго Hyper-V+WAC.
О, да. Гуглить реддит ceph war story (оно на самом деле не просто про цеф а именно про проксмокс и как оно классно все развалилось) - или искать тут - я вроде давал прямую ссылку пока она была актуальна.С другой стороны - тех кто тогда смог это починить, теперь поди уж точно не уволят.
А твою hyperv любой школьник может.
sdn- это software defined network.
каким местом к нему ceph?
Ну а с другой стороны - а что, еще кто-то есть?Не хочешь вот - gluster например попробовать? По глазам вижу что не хочешь. Гад.
А поверх storage direct в общем-то проще оставаться на hyper-v.
P.S. говорят, ruvds унаследовали от мастерхвоста эту чудо-технологию. И не кашлюют (не, ну а чего им плакать-то особенно)
Цена WAC?
Нисколько, качай вволю: http://aka.ms/WACDownload .
C ceph я пытался - честно, ну оно у меня вообще не срастается даже на начальных этапах.
Всё завожу, даю стресс-тест с внезапным отказом ноды - несколько блоков уходят в recovery и из него уже не выходят. Из форумов понял, что надо через задницу выкручивать crush map, чтобы этого не было, и решил, что нет, спасибо, если оно полностью развалится - будет не поднять.
И конфигурация-то примитивнейшая, 9 storage нод, три DC...
э... блин, ты себе территориально-распределенный что ли захотел? Не делай этого. Не для рассейских сетей сия затея.
попробуй проксу. Она тебе все правильно настроит. Один раз. Апгрейдить только не вздумай.Но в целом, конечно, пользовать эту хрень без редхата за спиной - надо быть очень самоуверенным или быстрым.
А чем iSCSI SAN не устраивает?
тем что его надо где-то отдельно размещать. Вот есть у тебя три делловских...э...много...ну пусть хуавеевских сервака. На них ты собрался развернуть свою виртуализацию, т.е. мощности самой кастрюле не занимать. Дисков при этом в сумме в них можно напихать вполне достаточно, даже в одноюнитовую кастрюлю влезают десятки терабайт. Напрашивается очевидное - не тратиться на отдельную сеть, отдельные железки и отдельные менеджемые единицы, а собрать sds прямо по месту.
Но тут на сцену выходит ceph и обоссывает зрителей, сидящих в третьем и двенадцатом ряду...(А вот у вмвари - работает... ну ребята из гринатома мамой клялись... но вроде убедительно.)
Не, ceph не выходит, его для Hyperconverged не рекомендовали никогда, вроде. После такого кастрюле придется мощности таки подзанять.
ну это ж зависит от того, сколько ее до того было.В моих экспериментах ничего особенного (память жрьеот, ну так ты думаешь наша продакшн стойка с нетапой не жрьот? Еще как, за обе щеки. И подавать непременно сертифицированную, с лейбачочком. Цена этой наклейки почему-то как у чемодана точно таких модулей но без наклеек.) - такого что не смог бы потянуть тот ящик что у нас штатно ставят под виртуализацию.
У меня не вышло чтоб оно при этом еще и не было аццким тормозом, но умные люди говорят что на меньше чем десятке тазиков и не должно было - а столько под эксперименты мне никто не дасть :-(
И не SDN, а SDS, наверное? Ну его в это самое.
Ого, вон оно как теперь можно, оказывается: **контейнеры** с иной архитектурой! Я раньше думал, что для таких штук надо полноценную виртуализацию использовать.> Allow riscv32 and riscv64 container architectures through the binfmt_misc kernel capability.
> After installing the qemu-user-static and binfmt-support packages one can use a RISC-V based rootfs image to run as container directly on an x86_64/amd64 Proxmox VE host.
И что, по-твоему, такое "qemu-user-static"?Логичненько, в общем - если вся система понастроена поверх qemu-kvm, достаточно заменить модуль на эмуляторный и все будет работать примерно так же - только тормоооооознооооо. Ну и что, как будто бы оно на рискве бы летало... если бы эти рискве еще вообще существовали не только в фантазиях.
А для подр...ть поотлаживаться - вполне сойдет. Вот и вполне реалистичное применение чудо-технологиям. Могет эта ваше хиперве такое, а, блингейц?!
qemu-user-static это всё же, как я понимаю, не полноценная виртуализация, а только транслятор команд.Да, тормозно. Но для некоторых целей вполне достаточно.
RISC-V железо вполне себе существуют, у меня уже две платки с микроконтроллерами — Sipeed Longan nano и SparkFun RED-V thing plus. Первая дешёвая прикольная, сразу с экранчиком, а на второй есть J-link. Я во всей этой теме пока ещё слабо разбираюсь, только начинаю.
так оно там для контейнера, судя по описанию и использованию модуля - то есть это не целиком вм а именно запуск чужого бинарника (но линуксного - т.е. взаимодействие с ядром идет с настоящим ядром без всякой виртуализации, просто команды выполняет интерпретатор - т.е. там тот же механизм что позволяет запускать java-бинарники...ну и bash на самом деле почти он же)фиг знает к какой полезной деятельности это можно применить, но скорее всего как и у тебя - непонятно но прикольно и почему бы не сделать.
По скорости может даже переплюнуть дешевые китайские платы ;-)
Вот дофига не могу понять - на фига вообще может понадобится КОНТЕЙНЕР с рисквой.
Ь
Он быстрее (в разы, потому что ядро - настоящее а не эмулируемое).
И не надо мучаться с загрузкой виртуальной системы, с которой могут возникнуть трудности, поскольку все они уникальные и никакого уефи для рисквы тоже нет.
А вот юзерленд может и будет работать.Я бы вот на такое в свое время посмотрел бы пристально - возможно сильно упростило бы мне отладку (не для рисквы понятен, но механизм-то универсальный)
Стартовать и работать с usb уже научили ?