Тип виртуального диска для KVM

Держим виртуальные диски сообразно задачам. Системные на SSD поверх glusterfs, БД прямо на LVM, хайлоад — на проброшенных SSD.

В твоём случае нужно знать объём и характер нагрузки.

LVM конечно.

Характер весьма простой. Клиенты соединяются и льют данные: маленькие файлики (2-4Мб) раскладываются по каталогам и дергается мускул, куда пишется семантика по файлу. Другие клиенты соответсвенно читают семантику и сосут файло. Софт на джава. Памяти достаточно. Клиентов отдающих и берущих не так много - пара десятков. Это не публичный сервис.

ССД как хранилище не используется на хостовой машины. Только для кеша в массиве.

И спасибо за ваш ответ. У вас публичное облако или корпоративное?

У нас корпоративное, частично нагруженное публичными сервисами.

Для указанного же случая достаточно будет и qcow2.

Файлик qcow2 в 1Тр ?

Ты сразу только учитывай как ты будешь резервировать такие объёмы. - Какие у тебя на сей счёт планы..? А как насчёт «живой» миграции/высокой доступности? - Что тебе надобно из этого? Ты об этом не сказал... А это как-бы важно...

Что мешает?

реальные разделы

будет стема на lvm, файло на хосте - экспорт NFS в виртуалки будет удобно бэкапить, мигрировать и тд

исправлено: будет система на lvm

Не очень понял твою идею.

Но я бы выбрал zfs, и гонял бы diff от снепшотов по сетке. На таких объёмах, не делать же каждый день full backup...

Резервирование на другой сервер. Это не проблема. Высокой доступности нет. Планирую живую миграцию вручную.

ZFS, виртуалки заливать на тома ZVOL.

to post-factum

Что мешает?

насчет файла в 1Тр? Да есть сомнения. Это все же файл. Если он грохнется (напр. по вине файлухи или ОС) наступит печаль и развертывание с бэкапа.

Рейли..? То есть ты боишься создавать файлы 1тб размера, ибо потому, что боишься, но в то же время тебя не заботит вообще никак вопрос резервирования..? - Да ты бессмертен!

Я сейчас решаю аналогичную задачу. У нас нету центральной СХД, есть ряд серверов которые умеют kvm. Хочется получить ферму управляемую из одной точки, с возможностью развернуть клон любой машины и подняться с резервной копии. Образы - будут большие. Некоторые планируются более террабайта. Резервные копии можно настраивать, + реплика.

опять zfs ради zfs

Не очень понял твою идею.

Host выступает в роли NAS для виртуалок (для хранения файлов). Под базу мускуля lv (logical volume). Под систему lv (обычно 8Гб хватает с головой для энтерпрайзных систем), под своп отдельный lv соотв. размера.

Самая объёмная часть это файлы, как я понял, они на NAS (nfs) при миграции машины мигрирует только система, при росте проекта можно мигрировать на корпоративный NAS, бэкап (rsync) на другой сервер без залезания в виртуалки.

ты боишься создавать файлы 1тб размера, ибо потому, что боишься..

Вы неправильные глаголы употребляете. Я не боюсь. Бояться отучили 20 лет назад в одной стране с жарким климатом. Я опасаюсь. Размер файла в террабайт на мой взгляд это неправильно.

И почему вы пишите что резервирование меня не заботит? Я ж написал - на другую машину будет литься. И для бэкапа - файл в терабайт явно не лучшее решение.

Ок. Пусть хост будет НАСом. Как это поможет при миграции? Если внешний НАС - мне понятно. В данном случает мигрируешь машины скажем для того чтобы обслужить хост (батарейку на кеше поменять). Тогда на целевом хосте (куда мигрируем) нужно создать копию инфраструктуры первого хоста, с насами и т.п. НФС же на первом хосте будет недоступна. Тогда в чем прелесть то?

Для этого есть RAID, зеркалирование с помощью распределённых ФС, а также бекапы.

главный спец по zfs, есть сервер делл, я там создал твою любимую и сделал её средствами raidz, это всё сделано на 3 sas дисках по 300 гб с 15к iops, как теперь информацию с этого, перенести на san dell с 12 sas дисками по 300 гб в 10 рейде?

Так гонять терабайт придется. И не один. Каждый раз. В файлике-диске хоть байт поменялся - гнать его целиком.

И рейд не причем. По вине ОС корумпировался файл - и как здесь поможет рейд? С точки зрения рейда - все законно. Зеркалирование - согласен. Мне понравился глустерфс. Но медленновато.

В файлике-диске хоть байт поменялся - гнать его целиком.

Что О_о?

И рейд не причем.

Это один из элементов построения отказоустойчивой СХД. Рейды спасают от вылета дисков, реплика кластерной ФС — от вылета рейд-контроллера или хоста, бекапы — от нежданчиков.

Но медленновато.

Как тестил?

raidz, это всё сделано на 3 sas дисках по 300 гб
перенести на san dell с 12 sas дисками по 300 гб в 10 рейде

Не очень понял какая связь между переносом данных и ZFS. У тебя san dell с 12 sas тоже zfs чтоли?

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

MD3800f

Снова не понимаю какая связь между ZFS и переносом данных. Если у тебя ZFS без ZVOL, то просто копируешь файлы на другой сторадж, если есть ZVOL, то копируй через dd, как с любого другого блочного устройства или монтируй тома и тоже копируй файлы, как тебе больше нравится.

да у меня уже там 4 zvol, я просто пока механизм работы этого делла не понимаю, там к нему даже софтина специальная, которая сабака написана на java и не хочет пока работать у меня в федоре. Буду ставить походу rhel workstation 7 на ноут, работодатель благо оплатит.

Ого... То есть ты вполне серьезно предлагаешь отдавать виртуальные машины по гигабитной сетке по NFS? Кроме файбер чанел ИМХО - все остальное это мусор. Какой нафиг NFS, там виртуалка неделю стартовать только будет с ним...

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

да у меня уже там 4 zvol

На ZVOL виртуалки? Если да, то через dd сливай тома на другой страдж.

Виртуалка на 1, на остальных по базе данных.

Смотри, ты можешь взять zfs и гонять только ту разницу которая у тебя изменилась... Без костылей, без rsync. На другой стороне маунтишь zfs том и видишь свои образы qcow2 машинок. Надо увеличиться - не проблемно! qcow2 это все умеет. Сейчас тебе там насоветуют lvm всяких будешь потом голову ломать, чего с этим дальше делать...

По террабайту в сутки? Там будет море безполезной нагрузки во время этого dd

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

есть динамические тома lvm, их можно безболезненно увеличивать.

Смотри, ты можешь взять zfs и гонять только ту разницу которая у тебя изменилась...

Даже если б у него была ZFS на втором сервере, всё равно нужно 1 раз полностью перебросить один снапшот и только потом можно кидать дифы.

У него всего 600Гб, по гигабитной сетке мухой сольётся.

буду думать как сливать, боюсь пока повредить тот сторандж

Читай доки, а то так и будешь боятся.

через неделю как раз и начну, доки с сайта делл уже скачал, хреново знакомый циcковик свалил из питера, думаю теперь как сделать связку 3800+mysql+AD.

Это один из элементов построения отказоустойчивой СХД. Рейды спасают от вылета дисков, реплика кластерной ФС — от вылета рейд-контроллера или хоста, бекапы — от нежданчиков.

Я 25 лет сисадмин. Не надо рассказывать о рейдах и уводить обсужление в сторону. И я не строю схд. Речь шла о другом. Не надо выдумывать несуществующих проблем и тут же описывать борьбу с ними.

Вы советуте виртуальную машину в файл. Практически это приведет к размеру файла в 1Тр. Конкретно у вас есть в работе виртуальные машины в файлах такого разъмера?

у меня на прошлой работе были базы данных по 1,5-2 тб, ты предлагаешь их тоже фигачить в виртуальные машины?у меня базы данных стояли на голом железе, фс и рейд контроллере за 80 шт.

to erzent

Скажите а зачем вы свои проблемы с zfs в этом треде обсуждаете? Недержание чтоль?

читай внимательно, не будешь выглядеть идиотом

кстати добрый человек, что можешь сказать про MD3800f, подключён к серверу делл через специальный кабель какой то, пока не разбирался, начнут как документацию сделаю по инфраструктуре и мониторинги настрою. Если использовал такое железо, какие проблемы были с ним?

чтобы не создавать новые, тем более тебе ответов уже дали достаточно, под твои задачи реально либо lvm либо zfs, zfs сложнее в настройке но проще в поддержке чем lvm.

Объемы небольшие, пофиг как и в чем, в чем привычней тем и пойдет. qcow будет занимать столько места, сколько данных в нем лежит, пока он до 1Т не дорастет - будет меньше. Тут вопрос больше в иопсах чем в пространстве.

без sas дисков о iops говорить бестолку.

без sas дисков о iops говорить бестолку

какой же ты все-таки ламер.