30 мая в 18:30 в ауд. 707 второго учебного корпуса МГУ (факультет ВМК, МГУ1С52) состоится семинар Александра Герасёва по теме «Системы хранения данных». Страница доклада здесь: uneex.mithril.cs.msu.su/Events/Storage

Доклад рассчитан на тех, кто пока мало что знает о СХД, SAN и тому подобных вещах (но хочет узнать больше), и на тех, кто готов вносить интересные комментарии; проходит в рамках семинара UNИX.

В здании факультета ВМК работает бюро пропусков. Для получения пропуска необходимо предъявить паспорт и сказать, на что вы идёте — и этого должно быть достаточно. В случае проблем в день семинара можно связаться с Артёмом Гавриченковым (это я) по телефону +7 916 515 4958 и в джаббере (ximaera@gmail.com).

P. S. С этой весны мероприятия UNИX начинают проходить более-менее регулярно, так что вопрос: насколько интересны подобные объявления в будущем?

31 мая 2008. Всем пришедшим спасибо, было круто!

Материалы лежат по следующим адресам:
uneex.mithril.cs.msu.su/Events/Storage
http://esyr.org/wiki/index.php/UNИX,_весна_2008,_04_семинар_(от_30_мая)
esyr.org/photo/uneex_08_05_30

Введение

Поставили передо мной как-то задачу… говорят один сервер это хорошо… но учитываю рост посетителей, неплохо бы было повысить производительность отдачи и для этой цели будет приобретен еще 1 сервер…
еще один сервер это хорошо, подумал я… только что с ним делать ??
Поговорив с програмистом и примерно поняв чего он хочет…

А именно одновременную отдачу контента, и что-то типа nfs или шары…
но тогда был бы оверхед ибо данные гонялись по сети и нагружен был бы диск одного сервера, посему надо было чтобы данные одновременно хранились на обоих серверах и реплицировались друг на друга…
поискав в гугле что-то на эту тему нашел информацию по кластерным фс, и для меня подходили gfs2 и позднее обнаруженная ocfs2, но была проблема в том что обычно использовалось выделенное файловое хранилище и его уже монтировали ноды… что было неприемлимо для меня, и тогда позадавав вопросы народу в конференции (gentoo@conference.gentoo.ru благо там были люди работающие с кластерами и прочими веселыми вещами) я вышел на drbd

Доброго времени суток. Недавно я задался вопросом о том, как делать горячие BackUp`ы MySQL-серверов — ниже компиляция из прочитанного. Заранее хочу сказать, что данный пост является скорее большой заметкой, чем полноценной статьёй. Я намеренно уклоняюсь от описания синтаксиса — на эту тему уже немало написано — я же ставил перед собой другую цель — составить краткий обзор основных методов с характерными особенностями:

Задача

Когда диски были маленькие, а Интернет большой, владельцы частных FTP-серверов сталкивались со следующей проблемой:
На каждом жестком диске создавалась папочка Video или Soft, и получалось так, что добавив новый жесткий диск, приходилось делать на нем папочки Video2, Soft2, etc.
Задача поменять жесткий диск на диск большего объема приводила к тому, что данные нужно было куда-то переносить, все это происходило нетривиально и с большими downtime'ами.
Разработанная нами система в 2005 году позволила собрать надежный и быстрый массив в 3 терабайта, масштабируемый, расширяемый, в режиме онлайн, добавляя диски или целые сервера с дисками.
Цена всего решения составляла 110% от стоимости самих дисков, т.е. по-сути, бесплатной, с небольшим overhead.

Вот примерная схема устройства нашего хранилища:

Немножко о работе с soft'овым RAID (mdadm) и LVM, возможно при наличии кучи свободного времени ЭТО превратится в какую-то приличную статью… а пока, лишь куча команд с краткими комментариями.

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

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

Вступление

Недавно мне потребовалось перенести несколько сайтов различных клиентов на нормальный выделенный сервер (не виртуальный). Я давно выбирал, где лучше арендовать сервер и выбором стала немецкая компания Hetzner Online и ее тарифный план DS 3000 (AMD Athlon 64 X2 4200+/2Gb DDR/2x160Gb HDD — как выяснилось потом — на сервере оказалось два винчестера по 320Гб).

Но мне не хотелось всех размещать на одном сервере. Поэтому было решено сделать виртуальные машины на базе технологии XEN (к тому же в придачу к серверу на ТП DS 3000 Hetzner Online бесплатно выдает 6 IP-адресов, которые очень удобно будут смотреться для отдельных проектов). В Сети можно найти много информации по теме настройки и самого XEN'а на Debian'e и настройки роутинга на нем, поднятии виртуалок на LVM (lvm дает большее быстродействие, чем виртуалки на базе image-файлов), даже в вики самой фирмы была информация об этом (но на немецком — Google Translate нам в помощь). Но. Было одно «Но». Она вся была разрозненная и кусками. Я нигде не смог найти толкового пошагового руководства для настройки «от» и «до».

Поэтому, всем кому интересна эта тема,

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

К счастью, решить большинство этих проблем в Linux может технология LVM. Она создаёт дополнительную абстракцию — логические тома, которые видны в системе, как обычные разделы, однако реально ими не являются. Эта технология очень полезна для серверов, однако и на домашних компьютерах она приходится очень к месту. Я больше не думаю, какого размера диск выделить под систему, чтобы какой-нибудь texlive не забил бы всё место, но и чтобы лишние 5 — 10 гигабайт не пропадали просто так. LVM имеет ряд существенных преимуществ, значительно упрощающих жизнь:

• Логические тома LVM больше не привязаны к физическому местоположению. В рамках LVM вообще не существует такого понятия, как порядок логических томов.
• Размер логических томов можно увеличивать прямо на лету, а у отмонтированных томов можно кроме того легко уменьшать размер, не выходя из системы.
• При необходимости можно размазать логические тома по нескольким физическим жёстким дискам, таким образом увеличив доступное место. При этом система всё так же будет видеть только один логический том, хотя размер его будет превышать доступные размеры жёстких дисков. Можно провести и обратную операцию, удалив жёсткий диск из LVM, таким образом освободив его для другого использования.
• LVM поддерживает механизм снапшотов — мгновенных копий файловой системы тома. Это может очень пригодиться для создания бекапов.
• Есть ещё масса плюсов, о которых можно почитать в специализированных статьях про LVM.

Подарили мне на работе на день рождения HP N36L Microserver за непонятные заслуги, чем весьма меня озадачили вопросом о наилучшем его применении. Так-то я давно мечтал заменить старенький HP DC4200 на что-то более компактное и, главное, с большим количеством места под жёсткие диски. Но больше смотрел на башенные корпуса, в которые можно было бы насовать пару-тройку корзин на пять 3.5”HDD. А тут такая оказия.

Прошерстил интернеты, почитал умных и не очень людей и, как водится у настоящих комсомольцев, решил идти своим путём.

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

Первая часть тут.

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

Представим что у нас есть виртуальная машина на LVM разделе, внутри которой так же есть LVM разделы. К примеру CentOS, при установке, по умолчанию, создает LVM-based разделы, за исключением /boot.

Задача:

добраться до данных в этих разделах с родительской машины.

Написано на реальных событиях.

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

Итак, приступим. Вводные данные:

• 7 дисков, 2 primary-раздела на каждом;
• 1й раздел 7и кратное зеркалирование (RAID1);
• 2й раздел RAID5, под которым крутится LVM.

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

По-умолчанию Citrix XenServer использует LVM системы хранения виртуальных машин на локальном хранилище. Данный вариант хранения имеет массу преимуществ перед VHD-файлами, но порой для удобства переноса или для создания общего хранилища необходимо использовать файловый режим хранения по аналогии с VMware ESX.
В данном руководстве я пошагово опишу как создать общий файловый репозиторий на локальном сервере Citrix XenServer.

Ввиду невозможности для меня публикации в блог «виртуализация», выложу пока здесь.

abstract: Этот пост описывает организацию системного диска на машинах в облаке и объясняет, почему именно так.

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

Мотивация

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

Вот проблемы, которые возникают в связи с этим:

• Возможность изменить размер диска и корневой файловой системы
• Возможность создать дополнительные разделы
• Возможность подключить диски от одной машине к другой
• С этого диска надо ещё и загрузиться

Наиболее примитивным решением является

Иногда мне приходится сталкиваться с заменой корневой файловой системы. Имея загрузочный диск и доступ к серверу, это не сложно. Однако, я хочу поделиться опытом замены корневой ФС удаленно, через ssh, без перезагрузки.

Причины для замены коневой ФС бывают разные:

• перевод / в LVM
• перевод / в mdraid
• замена типа файловой системы (ext3 => btrfs)
• уменьшение размера ФС (resize2fs)

Введение

На днях мой сотрудник удалил случайно несколько виртуалок в Citrix XenServer.
Все осложнилось тем что виртуальные машины оказались на snapshot дисках.
Под катом рассказываю как я их оттуда вынимал в отсутствии каких либо резервных копий и переносил на KVM.
Примеров команд много не делал, так как целью статьи было описание концепции. Внизу привел необходимые ссылки.

ownCloud представляет собой Open Source решение для организации своего собственного dropbox-подобного хранилища файлов. Кроме, собственно, синхронизации файлов доступны так же дополнительные возможности, как то: синхронизация контактов, календарей (наличествует поддержка CalDAV) и задач, фотогалерея, проигрыватель аудио (с поддержкой протокола Ampache). Сервис работает в многопользовательском режиме, есть функционал общих папок.

Клиенты синхронизации доступны для Windows / Mac / Linux / Android, версия для iOS, по заверениям разработчиков, в финальной стадии. Наличествует достаточно интересная, но пока экспериментальная функция External Storage, позволяющая монтировать Dropbox и GDrive в папку с ownCloud.

Важной для меня функцией в Android-клиенте является Instant Upload, автоматически загружающий видео и фотографии в облако сразу после съёмки, аналогично клиенту Dropbox.

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

В качестве хостинга можно выбрать VDS или домашний сервер на антресоли.

Рассмотрим вариант с «домашним сервером».

В многих местах вижу вопросы о том, как настроить ipv6 для контейнеров в proxmox, а так-же, почему не работает онлайн бекап.

Сам уже довольно давно пользуюсь proxmox для виртуализации openvz (разделение сервисов, тесты, дев. окружения) ну и все это крутится на hetzner.

О том, как установить и настроить proxmox — писать не буду, на Хабре в частности, да и в интернете в целом — этой информации полно. Не смотря на то, что лучший источник такой информации — официальный вики.

Но что в вики нет, так это того, как же правильно ставить proxmox на дебиан.

Активные пользователи Mac OS X наверняка помнят анонсированную 23 октября функцию Fusion Drive. Напомню, что она представляет из себя логическое объединение установленных в ваш Mac SSD и HDD. Объем единого диска будет равен сумме объемов SSD и HDD, но главные плюс — часто используемые файлы (например, ядро системы) Mac OS автоматически и прозрачно для пользователя размещает на более быстром SSD, а все прочие файлы на HDD.

Завалялась у меня тут инструкция, как включить LVM для корневой файловой системы на двух популярных dedicated-хостингах: Hetzner и ServerLoft. Публикую ее здесь.

LVM в Linux используется, в частности, чтобы единомоментно создавать «замороженные» снапшоты файловой системы, которые можно потом спокойно бэкапить, в то время как сервер продолжает работать. Это очень удобная функция, особенно для серверов баз данных: можно делать инкрементный бэкап базы данных, например, при помощи файлового rdiff-backup или duplicity (в том числе на удаленный FTP-сервер, бесплатное и быстрое место на котором предоставляют многие хостеры). Что касается RAID-1 (зеркалирование на 2 дисках), то оно абсолютно необходимо на сервере, чтобы при выходе из строя одного из дисков его можно было заменить, не останавливая машину. Конечно же, нужно ставить LVM поверх RAID-1.

Но беда в том, что ни Hetzner, ни ServerLoft не позволяют включить LVM при первичном создании машины «при помощи одной лишь мышки». Вместо этого они дают возможность установить один из фиксированных образов ОС, максимум что — с включенным RAID-1. Ниже — две инструкции, как переключить такую «налитую» машину на использование LVM для корневой файловой системы, а потом — короткий пример того, как работать со снапшотами. Работать будем с Ubuntu Server 12.04 minimal (для других ОС конфигурация может отличаться).