[kvm, xen] linked clone

Настолько всё печально..? Даже в VBox есть же...

А что Вы понимаете под удобством? Читал Вашу тему о проблемах с KVM. Чуть не плакал. Всё же стоит прежде чем разрождаться гневными отповедями сначала ознакомиться с темой, почитать документацию, почитать практики. KVM (да и нынешний Xen) очень удобные и практически уникальные средства. При должном подходе.

Для начала стоит понять, что ни KVM, ни Xen это не «программы», а средства управления гипервизором. Сами по себе они умеют только это. И всё. Остальная функциональность реализуется массой прочих сторонних средств. Нужно «горячее» клонирование образов дисковых хранилищ по сети — пожалуйста: смотрите в сторону DRDB и подобных средств. Есть и более простые инструменты. Только пердежа возмущённого поменьше.

Что такое «linked clone»?

Логично, просто уже конечно я привык, что VMware умеет сиё из коробки, VBox тоже, ну может подскажете что-то для этой функциональности?

Чем не понравился мой пердёж? MSSQL пробовали гонять?

Пардон, не DRDB, а, наоборот, — DRBD.

А это когда создаёшь машину, ставишь туда ОС. Потом создаёшь новую машину, но говоришь, что в качестве жёсткого диска используй ранее созданный образ, а все изменения от этого образа пиши в diff файл, diff файл и будет твоим жёстким диском.

То есть не надо ставить 100 раз операционку. И другие бенефиты появляются, в виде экономии дискового пространства.

VМvare может даже обновлять начальный образ, и изменения вкорячивать во все diff файлы, то есть не надо каждую машину обновлять ручками, обновил один образ, и готово.

Да, и MS SQL, и Oracle, и куча различного оборудования в самых разных мыслимых и не очень вариациях. Всегда возможности упирались в мою лень/невежество, а не в ограниченность ПО.

LVM

DRBD - медленный как я не знаю что... Ну ладно бы он по скорости, чёрт с ним, 85 метров/сек - хватает. Но вот если юзать режим sync, то лейтенси выходит чудовищное. А в режиме async пропадает смысл от drbd... - Окстись, ты попользуй его сперва... Попиши кучку мелких файлов на такие тома - ужаснись.

Есть снимки LVM, есть в конце-концов обычный dd в файл.

DRBD не медленный и латентность у него на 10G практически идентична обычным операциям внутри сас-диска.

Пока не могу себе представить как его можно сюда прикрутить, в снепшоты пока оно не умеет писать, или я сути не уловил? :)

DRBD - медленный как я не знаю что... Ну ладно бы он по скорости, чёрт с ним, 85 метров/сек - хватает. Но вот если юзать режим sync, то лейтенси выходит чудовищное. А в режиме async пропадает смысл от drbd...

А ты как хотел?!

Читайте про настройки TCP/IP-стэка по конкретные нужды.

Эм... А чем латентность зависит от ширины канала то? Какая разница, 10G/1G/100 ? Протокол то тот же tcp/ip

Вы просто от иного набора инструментов требуешь, чтобы он был аналогичен тому, к чему ты привык. Прямых аналогов нет. И они не нужны.

Латентность зависит от аппаратной реализации, от состояния среды передачи, от самого протокола, от его настроек. У меня с помощь DRBD реплицируются две высоконагруженные OLTP-системы. Кстати, и в режиме async смысл не пропадает.

Вот знаете, что я хочу сказать? Что когда спрашиваешь про реальные вопросы, ответов толковых ОЧЕНЬ мало, а как по пустоте потрындеть, так это да...

Ну ведь async может дать полный неконсистент, если потушить машину не правильно.

В целом Вы конечно верно говорите, OLTP на чём бегает то? У меня сложилось впечатление, что драйвера под Win не очень хорошие virtio.

И как бы Вы реализовали задачу когда надо развернуть быстро очень много однотипных вирт. машин на KVM? - Копирование начального образа не предлагать, сам знаю.

Копирование начального образца ;) Или автоматическая установка из единого хранилища, но это средствами самой гостевой ОС. Опираться на один снимок системы и затем писать дифференциальные изменения в какое-то иное хранилище способ, на мой взгляд, крайне ущербный — создаёт единую огромную такую, жирнющую точку отказа. Да и схему переусложняет. Но это на мой взгляд. По поводу несогласованности, которая может появиться — ну так любой инструмент стоит применять осознанно, учитывая все аспекты. Драйвера virtio есть разные. Свежие федоровские чаще всего довольно кривые. От рэд хата у меня ни разу никаких претензий не вызывали. Ты просто хочешь, чтобы тебе предложили то, к чему ты готов, что тебе привычно. Поэтому всё прочее для тебя «по пустоте потрындеть».

Нет, я хочу результата, и KVM я смотрел достаточно тщательно. Я не привык не к чему, я хотел решить рабочие задачи (не для дома же kvm играться), одной из таких задач была 1С, в связке с MSSQL, оно конечно может и на Linux уже работает, но на тот момент времени была только версия 8.1, где поддержка Linux была крайне сырой, по скорости работы, что файловый вариант, что с СУБД, одинакого было, только куча проблем с PostgresSQL было ещё, в общем не приемлемо, задачу виртуализовать сервер 1С я не выполнил средствами kvm, так-как поставив прости господи винды, и получив падение производительности в 10ть раз, я изрядно помучался и забил.

Также у меня была задача, прокинуть USBtoCOM девайс, в VM - не получилось ничего, и в VMWare кстати тоже, и даже прямое прокидывание USB контроллера MMU кажется обзыватется - мне не помогло нигде.

По поводу несогласованности, которая может появиться — ну так любой инструмент стоит применять осознанно, учитывая все аспекты.

А что значит от задачи? В какой такой задаче простите, может устроить результат, при падении питания на одной ноде, чтоб есть шанс получать полный неконсистент всех запущеных VM?

Уверен, что тщательность это не про Вас ;) В связке с тем же Слоном никаких отличных от МС Сикела проблем нет. Ну, окромя того, что Слона тоже нужно использовать осмысленно (к МС Сиквелу тоже относиться, но в куда меньшей степени). Как раз с последним проблемы. Это типично. Люди, которые занимаются 1С, обычно отличаются редкостным непрофессионализмом в сочетании с воинствующей глупостью. И, наверное, в своей убеждённости что всё кругом должно быть ровно так, как они себе представляют, по-своему правы. Ну так для подобного подхода есть масса (ну не то чтоб масса) коммерческих решений, где всё сделают за Вас люди, которые несколько лучше разобрались в теме, чем Вы. Предложите своему работодателю их услуги, коль сами не справляетесь.

По поводу DRBD и согласованности. У меня в хозяйстве есть два удалённых друг от друга узла, которые работают, по сути, в асинхронном режиме. Лаг в согласовании компенсируется за счёт надёжной схемы резервирования питания. В случае сбоя по питанию на ведущем узле, ведущий узел останавливает виртуализированные системы, затем завершается согласование, а после этого запускается резервный. На всё это уходит около десяти минут. Что с учётом статистики за год вполне укладывается в регламент по требованию к времени простоя.

USBtoCOM? В мусорку.

Дело в том, что я 1Сом не занимаюсь, им занимается наш аутсорс, и аутсорсеры сказали сразу, что если там будет PostGRE, или линукс - они с нами не сотрудничают. Это первое. Второе: эти аутсорсеры знакомые гл. буха. Третье: даже сами 1с писали, что 1с под постгре работает плохо. Ну и в десятых: на работе люди работают, и час простоя 1С вылезает в копеечку, мы попробовали постгре, не понравилось никому, начали там воркеры зависать и всё прочее... - Я в нём не шарю, ни в 1С ни в постгре. - Короче, что есть то есть.

DRBD - и согласованности, это всё хорошо, за тем исключением, что Ваша схема вызывает очень большие опасения в плане надёжности, у нас есть огромный бесперебойник, есть дизель-генератор, мелкие бесперебойники, два резервных электропитания и всё одно: они умудрились один раз за три года шарахнуть так капитально всё, что мало не показалось ни одному серверу, ибо мелкие БП пришлось в bypass переводить, т.к. они плохо работают когда у них на входе аппроксимированная синусойда от большого ИБП. --- Так что... Полетело у них всё, потухли все серверные во всех зданиях. Я думаю есть большая вероятность получить неконсистент VM при async в таком случае.

Да, есть несколько больших подстанций, и там есть быдло электросчётчики «Меркурий», и они вот юзают COM сети, и всё это гонится в USB, а там их говнософт это расшифровывает, no way... Как-то так.

Не уж-то я не адекватен?

С АИИС КУЕ тоже приходилось (и приходиться) работать, COM-станций тысячи, разных (продукции Меркурия, правда, слава богу, нет). Всё прекрасно работает в полностью виртуализированной среде.

Ключевое слово «знакомые гл. буха».

В плане надёжности моя схема никаких сомнений не вызывает. Все риски посчитаны и соответствующим образом застрахованы. У подобной схемы оказалась самая низкая себестоимость на жизненном цикле. Всё по-взрослому.

Не хочет этот говномеркурий пробрасываться никак :) Оно пробрасывается, только данные не хочет считывать со счётчиков.

Не очень понял, что будет если я случайно в серверной выдерну питание у ноды где машинки бегают? Ну или эта машинка повиснет... (Ну такое тоже ведь может быть), может ведь статься, так, что все машинки накроются после этого?

А может завтра прилетит огромный метеорит и мы все умрём )))

Накроются и чёрт с ними. Хотя это крайне маловероятно. Коммерческие данные сохраняются традиционным резервным копированием. А асинхронный кластер только для потенциального уменьшения времени простоя. Подобные решения все производные от стоимости риска.

Да я понял это уже в целом, просто я вот чего хочу понять: вот есть скажем обычная VM, на drbd с асинхронным режимом, вот упала нода мастер, что будет на слейве при подъёме с него? Часть данных не успела записаться, будет повреждение (коррупт), на уровне файла VM? Или просто как жёсткая перезагрузка на уровне ОС самой VM? Если на уровне самой VM, да чёрт бы с ним в общем-то, современные СУБД так или иначе не плохо по идее поддерживают целостность, и да бекапы конечно рулят. :)

для kvm есть, надо просто использовать снепшоты qemu-img

вообще, ESXi не корректно сравнивать с kvm/xen, потому что ESX это не гипервизор а операционная система с набором инструментов. В линуксе все они есть, просто надо знать как их использовать, или же брать систему управления которая их будет запускать «под капотом».