Смысл отказываться от raid? Экономия на спичках?

1. В бесплатной версии ESXi весьма проблематично мониторить какой-бы то нибыло RAID массив

2. Желательно купить я так понимаю второй RAID контроллер? Сейчас есть один, с батарейкой и кешем 512mb - дорогая игрушка...

3. Если в RAID не хватит места, придётся покупать все диски бОльшего объёма и пересобирать массив.

4. Сейчас в мат. плате куча свободных дырок SATA, тогда как на аппаратном RAID всего четыре диска только можно подключить SATA.

5. Диски нужно покупать уже RAID Edition, а это уже не копейки...

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

По-сабжу что-нибудь можете сказать?

1. Не используй ESX
2. Зачам такой крутой контроллер под raid1 на 2 диска?
3.А если на харде не хватает места, то ты воткнеш новый хард и оно магическим образом появится на первом харде?
4.так речь про один диск же вроде
5. При 2х дисках это целых 100-200 баксов. На еду не хватает?
По сабжу ничего не скажу

1. это самое вменяемое из промышленного стандарта.

2. что было куплено, то куплено. Какие альтернативы? Россыпь контролеров со 128мб кеша?

3. простой машин допустим. А значит: погасил сервер, добавил веник, перенёс данные. Дешёвый RAID всё равно hotspare не обеспечит.

4. да, один, кончится место на нём, добавится ещё и так далее.

5. хватает вполне. Просто интересно: а зачем тогда все эти чудеса журналируемых ФС?

1. Контроллеры в ESXi мониторятся на ура, нужно только поставить соответствующую приблуду внутрь ESXi. У меня и HP Smart Array и LSI контроллеры вполне себе рапортуют о статусе массивов, проблем нет.

2. rsnapshot выдаст тебе неконсистентные бэкапы.

В нормальных системах вроде Veeam используется фишка ESXi changed block tracking, когда сначала создается снапшот, а затем у ядра ESXi спрашивают, какие блоки изменились с последнего бэкапа. В итоге, измененные блоки считываются уже со снапшота, а сама ВМ уехала вперёд дальше работать, без простоя.

В твоем же случае, если ты будешь делать копию работающей машины, то получишь образ, в котором намешана куча изменений из разных моментов времени: Rsync считал часть vmdk, читает остальную часть, а в первой части уже произошли изменения. В итоге имеем дохлый бэкап.

В общем, не изобретай велосипед. Если важна лицензионность, возьми какой-нибудь Veeam Backup Free Edition и бэкапь им, там куча ограничений, но это всё равно лучше твоей гениальной идеи :)

И да, как ты собрался экспортировать диск с VMFS наружу для бэкапа?

Стоп, стоп, стоп.

Задача: Обеспечить ряд сервисов с нагрузкой до 130 чел. не бизнес-критичных данных таких как:

• jabber
• почта
• dns
• dhcp
• пропускная система (только подготовка отчётов)
• vpn
• ldap
• антивирус
• wiki, шмики...
• куча сервисов которые никогда не взлетят - всякое тестовое барахло.

Т.е. речь не идёт о ERP системах.

Так вот я говорю вот о чём: что ряд этих сервисов вполне может постоять день. - Есть полукритичные сервисы такие как e-mail, их можно вынести на RAID. Но опять-же день, можно и постоять раз в несколько лет (за последние пять лет, был один простой по причине отсутствия Интернет в наших мухосрансках - пережили).

И подумалось мне вот чего, а почему-бы не...:

Редко изменяемые данные (Операционные системы обеспечивающие функциональность всего этого добра): не сливать на NFS storage через export в OVA формат РУКАМИ в ESXi клиенте? - Повторюсь, что многие ОС не трогаются годами (т.к. являются ВНУТРЕННИМИ сервисами, и не имеют даже подключения к Интернет!).

Часто изменяемые данные: например почта, и СУБД для пропускной системы: сливать через скрипты например такие: Стопим СУБД, делаем snapshot, поднимаем СУБД - всё это добро чуть позже забирает сервер через rsnapshot. - т.е. это внутри виртуальных машин!

И вот я думаю: А что, если я буду мониторить S.M.A.R.T. на ESXi, если периодически буду проверять целостность backup (путём поднятия с них) и логи ВНУТРИ виртуальных машин на предмет ошибок ввода-вывода, может быть и не нужно всякие RAID и Veam Backup? - Появятся ошибки i/o поменяю диск, да и дело с концом. Свалится диск: поднимусь из OVA машин + раскатаю данные из rsnapshot.

P.S. Veeam Backup Free Edition - не будет работать с бесплатной ESXi.

P.P.S. до этого вопроса ESXi проработала три года без нареканий. - Делал full backup через скрипты которые раньше работали в ESXi v 4.x

P.P.P.S сейчас обновился до ESXi 5.1

Да, я смотрю у тебя много свободного времени, что ты этой всей хренотнёй собираешься заниматься вручную... Админы стараются всё автоматизировать, а ты наоборот :)

Ну вперёд как-бы, и с песней)

Как по мне, то если нет денег, то юзать надо рейд1 и надеятся на него. Про мониторинг я уже писал.

Так рейд1 не отменяет того что нужно делать периодически backup данных и бекап машин.

Покупать ПО конечно можно тоже. Но это потянет тогда за собой покупку нормального железа - что не очень хорошо, так-как мы и так огромные деньги платим производителям различного ПО - придётся купить ESXi Essential, и VeamBackup, а к ним желательно нормальный сервер backup, и желательно более серьёзный сервер виртуализации с фирменым ПО от тойже HP.

Я как раз таки зато: чтоб всё автоматизировать и забыть... - Но я не думаю что RAID-1 есть понацея от всех бед. Я особо вообще не занимаюсь backup ни в каком виде, что есть плохо... И вот думаю. Какой backup лучше? - Вообще никакого, такой как я предлагаю, или такой который стоит много денег.

Я особо вообще не занимаюсь backup ни в каком виде...

Перефразируя старое: «Админы делятся на 11 видов - тех, кто ещё не делает бэкапы, тех, кто уже делает бэкапы и тех, кто не понимает, почему видов 11»

RAID1 не пАнацея, ессесно. Особенно от тупости юзеров и смелых админов :) Бэкапы, ессесно, нужны и регулярно. Просто то, что ты предлагаешь, это себе же геморрой большой.

vSphere Essentials Plus стоит что-то около 200к рублёв, в него входит уже Data Protection, так что никакого veeam покупать, в принципе, не требуется.

Если не получается бэкапить виртуалки целиком, то бэкапь их изнутри обычными способами вроде Bacula.

Какой backup лучше?

Работающий. Так что проверьте работоспособность Вашего способа, а по факту уже решите, устраивает Вас он или нет.

Я, например, за вариант blind_oracle. Не пойму, Вы на свои деньги закупки планируете что ли? Или Вам данные совсем не жалко, что никакого бэкапа до сих пор нет?

Ну так я и предлагаю бекапить их через rsnapshot только, а не через bacula. Не более того. 200к дороговато конечно, дороговато... Не дадут таких денег. Полные бекапы машин руками, раз в иногда, бекап внутри машин программными средствами.

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

Да поставь ты уже KVM.

Да поставь ты уже KVM.

В предыдущих темах уже выяснили, что у него руки с KVM не дружат.

Это да... Дружить то дружат, но производительность не понравилась.

А для моих задач KVM пойдёт без вопросов? Накидайте перечень ПО плиз, что там сейчас можно запилить на базе Ubuntu LTS желательно.

Да поставь ты уже KVM.

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

Это да... Дружить то дружат, но производительность не понравилась.

О производительности чего идет речь?

Подскажите:

1. У меня будет вирт. машина объёмом 300 Gb, каким образом я смогу получить инкрементальный бекап раз в сутки? - Не гонять же 300 gb каждый день. - Если я правильно понимаю, то никак. Только делая снепшот, монтирутя, и применяя rsnapshot или bacula. - Да и не ясно как гость Windows тогда разруливать в таком свете.

2. Да и вообще что выбирать то? lvm, raw, qcow2? - Везде свои плюсы и минусы... Более всего импонирует qcow2, но... - То что он хранит снепшоты внутри себя не очень хорошо.

3. Что с выравниванием? Если я выберу qcow2, какой размер блока нужен в raid выставлять? А если поверх raid будет lvm, а поверх lvm файловая система для хранения уже образов qcow2? Какие чудеса будут с выравниванием секторов?

4. Очень много различных советов по i/o на kvm одни говорят одно, другие другое... - Что тоже не очень понятно в итоге что выбирать, ну что virtio это ясно, но вот все эти политики aio и политики кеша вводят в страх...

KVM - огромное приемущество, что это OpenSource без тупых ограничений по железу, что это тёплый и ламповый Linux, но огромный недостаток: оно не до конца стандартизированно. - К примеру в случае чего надо ещё будет постараться потом завести виртуалки к примеру в VMWare в случае чего... В той же ESXi нету тех вопросов которые я озвучил выше, кроме первого.

Ответите на мои вопросы?

Многоуважаемый (без иронии) Миронов Иван сказал, что я не осилятор, но так и слился похоже... А ведь это не столь простые и очевидные вопросы.

У меня была речь о сетевой производительности! Я так и не смог добиться того, чтоб 1С в сетевом режиме файлового варианта отдавала отчёты нормально... - То есть выглядило это так:

С рабочего места пользователя запускаем отчёт 1С физ. сервер. - 4 минуты.

С рабочего места пользователя запускаем отчёт 1С KVM. - 20 минут.

С самой KVM запускаем отчёт 1С - 10 минут.

Это были мои результаты, сами понимаете меня это не устроило... Точнее не сколько меня, сколько пользователей. Я пришёл к выводу что сетевой стек не смотря на virtio через все эти br интерфейсы пока пройдёт...

Я не отрицаю кривизну своих рук, но правда в ESXi эти проблемы уже решены сразу за счёт единого стандарта. Ошибиться в простом случае довольно сложно.

proxmox поставить не вариант? Там много плюшек.

У меня была речь о сетевой производительности! Я так и не смог добиться того, чтоб 1С в сетевом режиме файлового варианта отдавала отчёты нормально... - То есть выглядило это так:

У меня аналогично в файловом режиме по сети. Ввод вывод сетевой тормозит, это бесспорно.

Я не отрицаю кривизну своих рук, но правда в ESXi эти проблемы уже решены сразу за счёт единого стандарта. Ошибиться в простом случае довольно сложно.

Не приемлю проприетарный софт, хотя думаю Вы правы

P.S.: У меня 1С сервера все виртуализированы KVM (до 40 пользователей, 5 баз, у каждого по 2 базы запущено, 7-ка, 8-ка), используем терминал, производительность отличная, дисковый кеш (по начало медленно после ребута, потом все быстрее и быстреее, нужен ИБП), только надо гостю с запасом давать ресурсов, оверхед на лицо, но профит выше.

Я на некоторые вопросы могу ответить, чуть позже, если мой опыт интересует.

там нет ни чего, что нельзя было бы достичь отдельно без него. У таких коробок своя ниша, быстро стартануть. просто обслуживать. ИМХО

Я как раз и тестировал с первой версией proxmox. И вот эти результаты оттуда. Что-то тюнил, что-то настраивал, пробовал drbd прикручивать к нему. Оно работало, и без проблем. Но как обычно у таких решений бывает: не все фичи есть через web морду, и некоторые баги присутствуют. Что с Proxmox 2.x не слежу уже.

Интересует для расширения кругозора, и вообще умных людей всегда хорошо слушать.

Мне тоже очень не нравится пропиретарный софт, особенно фришный, т.к. не совсем ясно что будет с темже ESXi далее, сейчас от толстого клиента хотят отказаться, что будет далее остаётся только догадываться...

В общем конечно же интересно про выравнивание, и backup содержимого _БОЛЬШИХ_ VM. И в чём храните образы, и почему. И что будете делать, если завтра потребуется скажем одну машинку перенести на варьку.

Машину,точнее диск, можно сконвертировать.
А backup не проблема если можно машину выключить на пару минут в сутки.

Выключить можно. Но тут момент не в паре минут, для создания снепшота, а в том куда потом девать-то 300 гб снепшот... - Если изменилось то сто мегабайт данных в сравнении с бекапом суточной давности. - KVM насколько я понимаю вообще ничего не предлагает для этого. Пропиретарщики что-то предлагают, а открытое ПО до мейнстрима не доросло до такого ещё, да тут стандарты хранения у всех разные от raw до специализированных форматов...

Конвертировать то можно, но опять-же дело в объёмах. Одно дело сконвертировать 8гб из raw в vmdk, другое дело 300гб.

Выключаешь виртуалку. Делаешь rsync и включаешь виртуалку.

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

Да, и такой формат в общем-то является vmdk. Ну это не самое главное в жизни. Так что с этим вопросом можно не морочиться особо.

Вот смотрите получится-ли запилить такое:

KVM -> LVM -> raw образ виртуальной машины 300gb

Бекап запускаемый один раз в неделю:

• Выключаем VM
• Делаем snapshot от LVM
• Включаем VM
• C полученного снепшота делаем rsync

Подскажите пожалуйста: как добиться такого: на сервере backup должна быть возможность эту самую VM откатить на неделю, на две, на три назад. - Т.е. должен быть некий full backup и ТРИ инкремента к нему. - Т.е. должно не заниматься 900 gb, а должно заниматься: 300gb с хвостиком, хвостик: это изменения за три недели к full backup, и чтоб на каждый инкремент можно было откатиться. И чтоб не гонять каждую неделю по 300 gb, хотелось бы чтоб как rsync разбивало оно снепшот на чанки, и гоняло только контрольные суммы, и выдирало только те чанки которые имеют отличную сумму, но складывало это как-то отдельно. :) Такое бывает? Ну или типо такого.

А, хотя можно на сервере backup применить тоже lvm, и я получу то что хочу. Возможность иметь три актуальные копии - в снепшотах, это кстати также вполне устроит! Теперь вопрос: о чанках, и rsync, оно возможно такое?

rdiff-backup?

То есть на стороне backup сервера можно применить такую схему:

• На томе где лежит backup машины на 300гб делаем снепшот.
• Запускается rdiff-backup и у меня на сервере backup получается свежий файл.
• В сделанном ранее снапшоте - получится файл VM её предыдущего состояния
• Фактически места получается 300gb с хвостиком

Да я понимаю, что сервер backup несколько просядет по записи, из-за снепшотов, но не думаю что это критично будет.

Имеет идея право на жизнь?

Сори за поток сознания...

Вроде как это может делать и сам rdiff-backup, без LVM

Посмотри еще obnam. Интересная штука.

Я её как-то пугаюсь, идея хороша, но реализация сложна - много модулей...

Если не трудно ещё раз, всё же подскажите: rdiff-backup, это:

Если мне надо достать последний файл, я смогу это сделать прям файловым менеджером.

Если мне надо достать предыдущий файл - я буду делать это через утилиту которая будет смотреть в репозитарий rdiff-backup'a?

И каждый раз он не будет гонять все эти 300gb, а будет чекать суммы от чанков. Всё верно?

Если так, то в скоре ЛОР потрясёт следущая попытка далдона асилить KVM, и сделать всё по-человечески. :)

Все верно :)
Посмотри еще virt-back. Если совместить его с rdiff-backup то получится то что ты хочешь. Если осилишь конечно.

Мой взгляд

Система ввода/вывода, особенно сетевого слабовата. Действительно можно наблюдать большое снижение производительности даже при использовании virtio для сети. Как панацея пробрасывать PCI устройства. Сам не испытывал, но кажется производительность увеличивается.

Производительность дисковой подсистемы удалось поднять, в экспериментах, за счет использования virtio и writeback кеша. После старта гостя, некоторое время файловый ввод/вывод ускоряется. Чем больше памяти на хосте, тем лучше. Но следует следить за питанием.

В kvm, думаю лучше, отдавать блочные устройства, LVM тома. ИМХО так удобнее и судя по статьям интернет более производительно. К тому же такой подход дает возможность на живую делать снапшоты. В режиме снапшота файловый ввод/вывод замедляется, для компенсации данного поведения делаю снапшот на отдельный быстрый диск, лучше ssd, а после снятия сразу же отключаю снапшот и архивирую полученный файл. Если делать снапшот на что-то медленное, то гость win падает в синий экран c ошибкой viostor.sys (драйвер virtio).

В KVM гостей следует отдавать не один диск, а несколько, на одном диске система, на другом диске данные. Диск с системой и конфигурационный файл машины бэкапить единожды, либо раз в месяц. Данные бэкапить внутри гостя (полные+инкрементные). В случае восстановления, разворачивать систему, а поверх разворачивать данные.

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

Что касается того чего пробовал я: Я пробовал делать в 2010 году, или чуть ранее проброс PCI-E сетевой карты, т.е. у меня мат. плата хоста поддерживает данную технологию. Не могу сказать, что сильно ускорило это дело у меня 1С, детально я не разбирался уже чего оно и как, ибо результаты всё же продолжали сильно меня не устраивать.

Я тут стал ковыряться дальше, всё же весьма интересные утилиты тут посоветовали мне, в частности rdiff-backup (я и ранее знал об этой утилите, но не вникал особо), ну и ряд других. И в общем разгуглил я примерно такое:

На хост ESXi можно удалённо по ssh делать любой машине syspend, затем маунтить весь дисковый массив по sshfs прям на сервер backup и уже оттуда делать прям такую бяку: rdiff-backup /mnt/Esxi/VM1 /backup/VM1, после чего поднимать опять-же по ssh машину из syspend, конечно я отдаю себе отчёт в том, что машина будет простаивать по часу - если она большая, но на тестовой машине в 2гб сей процесс был буквально несколько минут. - Что конкретно для меня вполне терпимо. - И я имею засаспенжуную машину прямо на backup сервере, т.е. смогу поднять её где угодно на любом хосте бесплатного ESXi и она прям уже будет «горячая». - Да, но увы это нарушает лицензию бесплатного использования ESXi... Но всё-же... (Впрочем полные финальные тесты с откатами из репозитария rdiff я пока ещё не пробовал)

Что же касаемо моих настроек старой версии ESXi: обнаружил я вот чего: на RAID массиве RAID-10 сделал я страйпы по 256kb, т.е. при блоке FS от VMWare 1мб, я получаю четыре запроса в RAID. - Разумеется поправлю этот момент.

Вы так и не рассказали вот про что: я полностью согласен, что lvm наиболее правильный и верный путь в KVM, только вот что касаемо смещения Вы так и не рассказали.

Представим себе ситуацию: физический диск, mdadm, lvm. - Ну а там уже машинка бежит. - Где какое смещение нужно делать, чтоб попасть куда нужно? - Как обеспечить чтоб запрос из гостя полностью совпал с месторасположением на диске? - Ведь для KVM как я понимаю нет никакого ПО которое бы это диагностировало... - В целом же безразницы, главное это конечно отклик в самом госте. - Вы проводили какие-либо тесты? - ИМХО, более-ли менее приемлемо можно жить с откликом 10-15мс. на рандомном доступе к HDD. - Кстати такой отклик обеспечивает ESXi, располагая три VM на десктопном HDD. - В общем весьма интересно в этом плане послушать.

Чтоже касаемо игр с тем, что часть записи на диск VM будет кешироваться в ОЗУ, это очень рискованное дело. - Питание обеспечивать конечно можно, и штатное выключение сервера тоже. - Но уж больно пугает лично меня такая игра...

Ну и да: чтоже касаемо того, что Вы ОС держите в одном lvm томе, данные в другом... - Оно конечно не плохо. Но тупо папка с пятком файлов в ESXi выглядит куда более аппетитно в случае чего. - К примеру так было с почтой у нас, как только пропал Интернет, мы подумали как бы было здорово если бы почта была на вирт. хосте, можно было бы её поднять прям по-быстренькому у соседей...

И ещё: чем Вы делаете backup Ваших машинок со снепшотов? - ОЧЕНЬ интересно узнать.

К тому же такой подход дает возможность на живую делать снапшоты.

А Вы не боитесь, что получите неконсистент на выходе? Ведь в этом случае Вы даже sync внутри самой VM не делаете... - А если ещё и играетесь с writeback, то шанс того что получите муру неконсистентную в снепшоте многократно возрастает.

А Вы не боитесь, что получите неконсистент на выходе? Ведь в этом случае Вы даже sync внутри самой VM не делаете... - А если ещё и играетесь с writeback, то шанс того что получите муру неконсистентную в снепшоте многократно возрастает.

Теоретически для этого есть место, но мнения разделяются даже на ЛОР по этой теме. Практически все ок. Есть некоторые машины, которые нагружены круглые сутки. Поэтому либо данный подход, либо, как я думала чуть ранее, использовать DRBD.

• на время бэкапа разрывать связь;
• делать вторичный сервер главным;
• снимать даные;
• восстанавливать связь;
• синхронизировать;

Хотя здесь тоже можно найти, возможности для плохого.

В целом, то что скажете о моих рассуждениях? Здраво сужу?

Что касаемо drbd: пробовал я и эту штуку. Делал агрегацию двух сетевых карт Intel по гигабиту, и гонял в режиме slave/master, гонял виртуалочки - как гость была WinXP, я делал sync синхронизацию нод - опять-же для консистентности. - Синхронизация нод была около 80 мегабайт в секунду первоначально (Скорость хороша, но лейтенси которое привносит tcp стек...). - Всё остальное же меня расстоило. То есть виртуалочка ну совсем была полуживая внутри drbd, всё работало, но большие уж дюже задержки приключались. Это был опять-же 2010 год. Но не думаю, что сейчас всё принципиально новое. Если гонять dhcp, dns сервисы, почту - сгодится. СУБД для ERP даже для небольшой - однозначно нет.

Так Вы так и не рассказали чем backup делаете со снепшотов.

И что по выравниванию? По лейтенси внутри гостя.

В целом, то что скажете о моих рассуждениях? Здраво сужу?

Все это тестировать необходимо и для работы условия аппаратные соблюдать.

Что касаемо drbd:

Агрегировал 4 порта сетевых карт Intel. DRDB в режиме A. Технические характеристики уже не вспомню. Все ок.

Синхронизация нод была около 80 мегабайт в секунду первоначально

Все зависит и от железа тоже, а не только от софта.

Так Вы так и не рассказали чем backup делаете со снепшотов.

bacula и скрипты перед и после задания.

И что по выравниванию?

Не выравнивал ни чего кроме физических дисков.

Ну в общем не плохо бы конечно посмотреть на тесты i/o к примеру на Ваших конфигурациях внутри машинок. - Кстати 80 мегабайт в секунду то на самом деле вполне хватает для большинства задач, тут я думаю что преодолеть лейтенси: drbd + tcp/ip - не в силах агрегация.

1. В бесплатной версии ESXi весьма проблематично мониторить какой-бы то нибыло RAID массив

Если производитель raid'а даёт пакеты с утилитами для своего raid'а - без проблем. Ставишь пакет, включаешь ssh доступ и время от времени опрашиваешь.

тут я думаю что преодолеть лейтенси: drbd + tcp/ip - не в силах агрегация

iSCSI так же поверх tcp/ip