Книга администратора Debian


mdadm /dev/md1 --remove /dev/sde



Pdf просмотр
страница22/32
Дата13.11.2016
Размер7.63 Mb.
Просмотров5082
Скачиваний0
ТипРеферат
1   ...   18   19   20   21   22   23   24   25   ...   32
mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
#
mdadm --detail /dev/md1
/dev/md1:
[...]
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2 2 8 80 1 active sync /dev/sdf
После этого диск может быть физически извлечён из сервера при следующем отключении, или даже из работающего сервера, если аппаратная конфигурация
позволяет горячую замену. Такие конфигурации включают некоторые контроллеры SCSI,
большинство SATA-дисков и внешние накопители, работающие через USB или Firewire.
12.1.1.3. Создание резервной копии настроек
Большая часть метаданных, касающихся томов RAID, сохраняется непосредственно на дисках, входящих в эти массивы, так что ядро может определить массивы и их компоненты и собрать их автоматически при запуске системы. И всё же резервное копирование конфигурации крайне желательно, поскольку такое определение не защищено от ошибок, и следует ожидать, что оно наверняка даст сбой в самый неподходящий момент. В нашем примере, если бы отказ диска sde был настоящим (а не симулированным), и система перезагрузилась бы без удаления этого диска, он мог бы начать работать опять, поскольку был бы обнаружен при перезагрузке. Ядро получило бы три физических элемента, каждый из которых заявлял бы, что содержит половину одного и того же тома RAID. Другой источник путаницы может возникнуть, когда тома
RAID с двух серверов переносятся на один и тот же сервер. Если бы эти массивы работали нормально до того, как диски были перемещены, ядро смогло бы обнаружить и пересобрать пары корректно; но если перемещённые диски были бы объединены в md1
на прежнем сервере, а на новом сервере уже был бы md1
, одно из зеркал было бы переименовано.
Поэтому резервное копирование важно хотя бы для справки. Стандартный путь для этого — редактирование файла
/etc/mdadm/mdadm.conf
, пример которого приводится здесь:
Пример 12.1. Конфигурационный файл mdadm
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

# This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100
# by mkconf 3.2.5-3
Один из наиболее важных элементов здесь — опция
DEVICE
, в которой перечисляются устройства, на которых система будет автоматически искать компоненты томов RAID во время запуска. В нашем примере мы заменили значение по умолчанию, partitions containers
, на явный список файлов устройств, поскольку мы выбрали использование целых дисков, а не только разделов, для некоторых томов.
Последние две строки в нашем примере позволяют ядру безопасно выбирать, какой номер тома какому массиву следует назначить. Метаданных, хранящихся на самих дисках, достаточно для пересборки томов, но не для определения номера тома (и соответствующего имени устройства
/dev/md*
).
К счастью, эти строки могут быть сгенерированы автоматически:
#
mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464
Содержимое этих последних двух строк не зависит от списка дисков, входящих в том.
Поэтому нет необходимости перегенерировать эти строки при замене вышедшего из строя диска новым. С другой стороны, следует аккуратно обновлять этот файл при создании или удалении массива RAID.
12.1.2. LVM
LVM, или менеджер логических томов (Logical Volume Manager), — другой подход к абстрагированию логических томов от их физических носителей, который фокусируется на увеличении гибкости, а не надёжности. LVM позволяет изменять логические тома прозрачно для приложений; к примеру, можно добавить новые диски,
перенести на них данные, удалить старые диски без отмонтирования тома.
12.1.2.1. Принципы работы LVM
Такая гибкость достигается за счёт уровня абстракции, включающего три понятия.
Первое, PV (физический томPhysical Volume), ближе всего к аппаратной стороне: это могут быть разделы на диске, целый диск или иное блочное устройство (в том числе и
RAID-массив). Обратите внимание, что когда физический элемент настроен на использование в роли PV для LVM, доступ к нему должен осуществляться только через
LVM, иначе система будет сбита с толку.
Несколько PV могут быть объединены в VG (группу томовVolume Group), которую можно сравнить с виртуальными расширяемыми дисками. VG абстрактны и не имеют представления в виде файла в структуре иерархии
/dev
, так что риска использовать их напрямую нет.

Третий тип объектов — LV (логический томLogical Volume), который является частью VG; если продолжить аналогию VG с диском, то LV соответствует разделу. LV
представляется как блочное устройство в
/dev и может использоваться точно так же, как и любой физический раздел (как правило — для размещения файловой системы или пространства подкачки).
Важно, что разбиение VG на LV совершенно независимо от его физических компонент
(PV). VG с единственным физическим компонентом (например диском) может быть разбита на десяток логических томов; точно так же VG может использовать несколько физических дисков и представляться в виде единственного большого логического тома.
Единственным ограничением является то, что, само собой, общий размер, выделенный
LV, не может быть больше, чем общая ёмкость всех PV в группе томов.
Часто, однако, имеет смысл использовать однородные физические компоненты в составе VG. К примеру, если доступны быстрые диски и более медленные, быстрые можно объединить в одну VG, а более медленные — в другую; порции первой можно выдавать приложениям, требующим быстрого доступа к данным, а вторую оставить для менее требовательных задач.
В любом случае помните, что LV не закреплены за конкретным PV. Можно повлиять на то, где физически хранятся данные с LV, но эта возможность не требуется для повседневного использования. С другой стороны, когда набор физических компонентов
VG меняется, физические места хранения, соответствующие конкретному LV, можно переносить между дисками (в пределах PV, закреплённых за VG, разумеется).
12.1.2.2. Настройка LVM
Давайте пройдём шаг за шагом процесс настройки LVM для типичного случая: мы хотим упростить чрезмерно усложнённую ситуацию с хранилищами. Такое обычно получается в результате долгой и витиеватой истории накопления временных мер. Для иллюстрации возьмём сервер, на котором со временем возникала потребность в изменении хранилища, что в конечном итоге привело к путанице из доступных разделов,
распределённых по нескольким частично используемым дискам. Если более конкретно,
доступны следующие разделы:
на диске sdb
— раздел sdb2
, 4 ГБ;
на диске sdс
— раздел sdс3
, 3 ГБ;
диск sdd
, 4 ГБ, доступен полностью;
на диске sdf
— раздел sdf1
, 4 ГБ, и раздел sdf2
, 5 ГБ.
Кроме того, давайте считать, что диски sdb и sdf быстрее двух других.
Наша цель — настроить три логических тома для трёх разных приложений: файлового сервера, требующего 5 ГБ дискового пространства, базы данных (1 ГБ), и некоторое пространство для резервных копий (12 ГБ). Первым двум требуется хорошая производительность, а резервные копии менее критичны к скорости доступа. Все эти
ограничения не позволяют разделы сами по себе; используя LVM, можно абстрагироваться от физического размера устройств, так что единственным ограничением является общее доступное пространство.
Необходимые инструменты находятся в пакете lvm2 и его зависимостях. После их установки настройка LVM проходит в три шага, соответствующих трём уровням организации.
Первым делом мы подготавливаем физические тома с помощью pvcreate:
#
pvdisplay
#
pvcreate /dev/sdb2
Physical volume "/dev/sdb2" successfully created
#
pvdisplay
"/dev/sdb2" is a new physical volume of "4.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sdb2
VG Name
PV Size 4.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID 0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I
#
for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
Physical volume "/dev/sdc3" successfully created
Physical volume "/dev/sdd" successfully created
Physical volume "/dev/sdf1" successfully created
Physical volume "/dev/sdf2" successfully created
#
pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/sdb2 lvm2 --- 4.00g 4.00g
/dev/sdc3 lvm2 --- 3.09g 3.09g
/dev/sdd lvm2 --- 4.00g 4.00g
/dev/sdf1 lvm2 --- 4.10g 4.10g
/dev/sdf2 lvm2 --- 5.22g 5.22g
Пока всё идёт неплохо; отметим, что PV может быть размещён как на целом диске, так и на отдельном его разделе. Как показано выше, команда pvdisplay выводит список существующих PV, с двумя возможными форматами вывода.
Теперь давайте соберём эти физические элементы в VG с помощью vgcreate. Мы соберём PV с быстрых дисков в VG под названием vg_critical
; другая VG, vg_normal
,
будет также включать более медленные элементы.
#
vgdisplay
No volume groups found
#
vgcreate vg_critical /dev/sdb2 /dev/sdf1
Volume group "vg_critical" successfully created
#
vgdisplay
--- Volume group ---
VG Name vg_critical

System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 8.09 GiB
PE Size 4.00 MiB
Total PE 2071
Alloc PE / Size 0 / 0
Free PE / Size 2071 / 8.09 GiB
VG UUID bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp
#
vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
Volume group "vg_normal" successfully created
#
vgdisplay -C
VG #PV #LV #SN Attr VSize VFree vg_critical 2 0 0 wz--n- 8.09g 8.09g vg_normal 3 0 0 wz--n- 12.30g 12.30g
И снова команды довольно просты (и vgdisplay предоставляет два формата вывода).
Заметьте, что можно использовать два раздела одного физического диска в двух разных
VG. Мы использовали приставку vg_
в именах наших VG, но это не более чем соглашение.
Теперь у нас есть два «виртуальных диска» размером около 8 ГБ и 12 ГБ
соответственно. Давайте разделим их на «виртуальные разделы» (LV). Для этого потребуется команда lvcreate и несколько более сложный синтаксис:
#
lvdisplay
#
lvcreate -n lv_files -L 5G vg_critical
Logical volume "lv_files" created
#
lvdisplay
--- Logical volume ---
LV Path /dev/vg_critical/lv_files
LV Name lv_files
VG Name vg_critical
LV UUID J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
LV Write Access read/write
LV Creation host, time mirwiz, 2015-06-10 06:10:50 -0400
LV Status available
# open 0
LV Size 5.00 GiB
Current LE 1280
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256

Block device 253:0
#
lvcreate -n lv_base -L 1G vg_critical
Logical volume "lv_base" created
#
lvcreate -n lv_backups -L 12G vg_normal
Logical volume "lv_backups" created
#
lvdisplay -C
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_base vg_critical -wi-a--- 1.00g lv_files vg_critical -wi-a--- 5.00g lv_backups vg_normal -wi-a--- 12.00g
При создании логических томов обязательны два параметра; они должны быть переданы
lvcreate как опции. Имя создаваемого LV указывается с опцией
-n
, а его размер обычно указывается с опцией
-L
. Конечно, нужно ещё указать имя VG, который следует использовать, отсюда последний параметр командной строки.
УГЛУБЛЯЕМСЯ Опции lvcreate
У команды lvcreate есть ряд опций для тонкой настройки создания LV.
Сначала опишем опцию
-l
, с которой размер LV может быть указан в количестве блоков (в противоположность
«человеческим» единицам, которые мы использовали выше). Эти блоки (называемые PE — физическими
экстентами, Physical Extents — в терминологии LVM) являются непрерывными единицами хранения на PV, и они не могут быть распределены между LV. При необходимости указать пространство для LV с некоторой точностью,
например для использования всего доступного пространства, опция
-l может оказаться полезнее, чем
-L
Также можно указать физическое размещение LV, чтобы его экстенты физически размещались на конкретном PV
(разумеется, из числа выделенных для VG). Поскольку мы знаем, что sdb быстрее sdf
, мы можем предпочесть записать lv_base туда, если хотим дать преимущество серверу баз данных по сравнению с файловым сервером.
Командная строка будет выглядеть так: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Обратите внимание, что эта команда может завершиться с ошибкой, если на PV недостаточно свободных экстентов. В нашем примере имеет смысл создать lv_base раньше lv_files чтобы избежать такой ситуации — или освободить немного места на sdb2
с помощью команды pvmove.
Созданные логические тома появляются как блочные устройства в
/dev/mapper/
:
#
ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jun 10 16:52 control lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2
#
ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2
ЗАМЕТКА Автоматическое определение томов LVM
Когда компьютер загружается. сценарий
/etc/init.d/lvm сканирует доступные устройства; те, которые были инициализированы как физические тома LVM регистрируются в подсистеме LVM, принадлежащие к группам томов собираются, и соответствующие логические тома запускаются и делаются доступными. Поэтому нет необходимости редактировать конфигурационные файлы при создании или изменении томов LVM.
Обратите внимание, однако, что резервная копия конфигурации элементов LVM (физических и логических томов и групп томов) сохраняется в
/etc/lvm/backup
, что может пригодиться при возникновении проблем (или просто чтобы
мельком взглянуть под капот).
Для облегчения жизни также создаются символические ссылки в каталогах,
соответствующих VG:
#
ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0
#
ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2
LV можно использовать в точности как обычные разделы:
#
mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 3145728 4k blocks and 786432 inodes
Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
#
mkdir /srv/backups
#
mount /dev/vg_normal/lv_backups /srv/backups
#
df -h /srv/backups
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups 12G 30M 12G 1% /srv/backups
#
[...]
[...]
#
cat /etc/fstab
[...]
/dev/vg_critical/lv_base /srv/base ext4 defaults 0 2
/dev/vg_critical/lv_files /srv/files ext4 defaults 0 2
/dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2
С точки зрения приложений, множество маленьких разделов теперь представлены в виде одного 12-гигабайтного тома с удобным именем.
12.1.2.3. Эволюция LVM
Хотя возможность объединять разделы или физические диски и удобна, не она является главным преимуществом LVM. Её гибкость особенно заметна с течением времени, когда возникают потребности в изменениях. Допустим, что в нашем примере возникла потребность в сохранении новых больших файлов, и что LV, выделенный файловому серверу, слишком мал для них. Поскольку мы использовали не всё пространство,
доступное на vg_critical
, мы можем увеличить lv_files
. Для этого мы используем команду lvresize, затем resize2fs чтобы соответствующим образом подогнать файловую систему:
#
df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 5.0G 4.6G 146M 97% /srv/files

#
lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao-- 5.00g
#
vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 8.09g 2.09g
#
lvresize -L 7G vg_critical/lv_files
Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents).
Logical volume lv_files successfully resized
#
lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao-- 7.00g
#
resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1835008 (4k) blocks long.
#
df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 6.9G 4.6G 2.1G 70% /srv/files
ОСТОРОЖНО Изменение размера файловых систем
Размеры не всех файловых систем можно изменять во время работы; поэтому изменение размера тома может потребовать отмонтирования файловой системы в начале и обратного монтирования её в конце. Разумеется, при желании уменьшить пространство, выделенное под LV, файловая система должна быть уменьшена первой; при изменении размера в другом направлении порядок обратный: логический том должен быть увеличен прежде, чем файловая система на нём. Это вполне очевидно, ведь файловая система никогда не должна быть больше блочного устройства, на котором она размещается (будь это устройство физическим разделом или логическим томом).
Файловые системы ext3, ext4 и xfs могут быть увеличены онлайн, без размонтирования; уменьшение требует размонтирования. Файловая система reiserfs позволяет изменение размера онлайн в обоих направлениях. Преклонная ext2 не позволяет ни того, ни другого, и всегда должна быть отмонтирована.
Мы могли бы, действуя тем же образом, расширить том, на котором размещается база данных, только мы достигли предела доступного места на VG:
#
df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 1008M 854M 104M 90% /srv/base
#
vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 8.09g 92.00m
Это не имеет значения, поскольку LVM позволяет добавлять физические тома в существующие группы томов. Например, мы заметили, что на разделе sdb1
,
использовавшемся вне LVM, размещались только архивы, которые можно переместить на lv_backups
. Теперь можно утилизировать его и ввести в группу томов, тем самым восстановив доступное пространство. Для этой цели существует команда vgextend.
Само собой, раздел должен быть предварительно подготовлен как физический раздел.
Когда VG расширена, мы можем использовать такие же команды, как и раньше, для увеличения логического тома, а затем файловой системы:

#
pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
#
vgextend vg_critical /dev/sdb1
Volume group "vg_critical" successfully extended
#
vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree vg_critical 3 2 0 wz--n- 9.09g 1.09g
#
[...]
[...]
#
df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 2.0G 854M 1.1G 45% /srv/base
УГЛУБЛЯЕМСЯ Более подробно о LVM
LVM угодит и более опытным пользователям, позволяя задавать вручную множество параметров. Например,
администратор может настроить размер блоков, составляющих физические и логические тома, как и их физическое размещение. Также можно перемещать блоки между PV, к примеру для тонкой настройки производительности или, в более прозаичном случае, чтобы освободить PV, когда необходимо извлечь соответствующий физический диск из
VG (чтобы присоединить его к другой VG или вовсе удалить из LVM). Страницы руководства, описывающие команды, в целом ясны и подробны. Для начала хорошо подойдёт страница lvm(8).
12.1.3. RAID или LVM?
Как RAID, так и LVM предоставляют бесспорные преимущества как только мы выходим за рамки простейшего случая настольного компьютера с одним жёстким диском, где схема использования не меняется с течением времени.
Есть несколько простых примеров, где вопрос выбора не встаёт. Если требуется защитить данные от аппаратных сбоев, безусловно следует создать RAID на избыточном дисковом массиве, ведь LVM просто не предназначен для решения этой проблемы. Если,
с другой стороны, требуется гибкая система хранения, где тома не зависят от реальных физических дисков, RAID мало чем поможет, и естественно выбрать LVM.
ЗАМЕТКА Если производительность имеет значение…
В случаях, когда важна скорость ввода-вывода, особенно время доступа, использование LVM и/или RAID в какой- либо из возможных комбинаций может повлиять на производительность, и это может оказаться важным фактором при выборе одной из них. Однако эти различия в производительности крайне малы, и заметны в очень немногих случаях. Если важна производительность, лучшим выбором будет использование накопителей без вращающихся частей (твердотельных накопителей, или SSD); их удельная стоимость за мегабайт выше, чем у обычных жёстких дисков, и их вместимость обычно меньше, но они обеспечивают превосходную скорость случайного доступа. Если характер использования предполагает много операций ввода-выводы, распределённых по всей файловой системе, например в случае баз данных, где часто выполняются сложные запросы, преимущество использования SSD значительно перевесит то, что можно выжать, выбирая между LVM поверх RAID и обратным вариантом. В таких ситуациях выбор должен определяться иными соображениями, нежели скорость, поскольку вопрос производительности легче всего решается использованием SSD.
Третий характерный случай — когда хочется просто объединить два диска в один том из соображений производительности или чтобы иметь единую файловую систему, которая больше любого из доступных дисков. В этом случае подходят как RAID-0 (или даже
linear-RAID), так и том LVM. В такой ситуации, если нет дополнительных ограничений
(вроде унификации с другими компьютерами, на которых используется только RAID),
более предпочтительным часто является выбор LVM. Начальная настройка несколько более сложна, но это небольшое увеличение сложности более чем покрывается дополнительной гибкостью, которую привнесёт LVM, если потребности изменятся, или если понадобится добавить новые диски.
Ну и конечно, есть ещё по-настоящему интересный случай, когда систему хранения нужно сделать одновременно устойчивой к аппаратным сбоям и гибкой, когда дело доходит до выделения томов. Ни RAID, ни LVM не могут удовлетворить обоим требованиям сами по себе; не страшно, в этом случае мы используем их одновременно
— точнее, одно поверх другого. Схема, включающая всё и ставшая стандартом с тех пор,
как RAID и LVM достигли стабильности, заключается в обеспечении сначала избыточности группировкой дисков в небольшое число RAID-массивов и использовании этих массивов в качестве физических томов LVM; логические разделы будут потом выделяться из этих LV для файловых систем. Преимущество такой настройки заключается в том, что при отказе диска потребуется пересобрать только небольшое число RAID-массивов, тем самым экономя время, которое потребуется администратору на восстановление.
Возьмём конкретный пример: отделу связей с общественностью Falcot Corp требуется рабочая станция для редактирования видео, но бюджет отдела не позволяет приобрести полный комплект оборудования класса high-end. Решено отдать предпочтение оборудованию, специфичному для работы с графикой (монитору и видеокарте), а для хранения использовать оборудование общего назначения. Однако, как общеизвестно,
цифровое видео предъявляет определённые требования к хранилищу: объём данных велик, а скорость чтения и записи важна для производительности системы в целом
(больше чем типичное время доступа, к примеру). Эти требования должны быть удовлетворены с помощью обычного оборудования, в данном случае двух жёстких дисков SATA объёмом по 300 ГБ; также необходимо сделать системные данные устойчивыми к аппаратным сбоям, в то время как обрабатываемое видео менее важно,
поскольку оно ещё записано на видеокассеты.
Чтобы удовлетворить этим требованиям, совмещены RAID-1 и LVM. Диски подключены к двум разным SATA-контроллерам для оптимизации параллельного доступа и снижения риска одновременного отказа, поэтому они представлены как sda и sdc
. Они размечены одинаково по следующей схеме:
#

Каталог: wp-content -> uploads -> 2016
2016 -> Государственное областное бюджетное
2016 -> В. П. Зинченко писал о том, что если человек в детстве не дополучил некую норму участия в игровом времяпрепровождении, он приобретает социально-психологическую ущербность вроде «игровой дистрофии», которую в последу
2016 -> Общешкольное родительское собрание «Об ответственности родителей за воспитание детей»
2016 -> 1 июня 2016 года Международный день защиты детей 1 июня
2016 -> «Формирование социально-нравственной позиции дошкольников посредством введения сказочных сюжетов в компьютерные дидактические игры»
2016 -> Принята Утверждена
2016 -> Конкурс по разработке компьютерных игр патриотической направленности «патриот by»


Поделитесь с Вашими друзьями:
1   ...   18   19   20   21   22   23   24   25   ...   32


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал