Centos 7 ssd настройка
Обновлено: 05.07.2024
Добрый день!
Только начинаю постигать премудрости Линукса. Пользуюсь вестой уже пол-года, полет нормальный. Но ставил CentOS 6.6 а потом и 7 с настройками "по дефолту".
Сейчас хочу собрать второй сервер, и может есть возможность сделать все оптимальнее.
Предполагается 128 Гб SSD + 6 Гб оперативной памяти. При установке CentOS как вы порекомендуете разбить диск. Или не заморачиваться и все оставить по "дефолту".
Post by skurudo » Tue Feb 09, 2016 11:03 am
Раньше бы меня, наверное, закидали бы ссаными тряпками за такие советы, но время стали проще, диски дешевле и ширше. Давайте вместо подумаем, что у нас тут за дела? У нас есть ssd - 1 шт или 2 шт в зеркале, 120 гиг места. Куда оно уйдет? 1) система и системные файлы, программы 2) пользовательские файлы 3) база данных 4) логи. Что у нас вероятнее всего будет жрать место? Обычно это пользовательские файлы. Но здесь встает вопрос - а зачем делить диск специально под них? К тому же настолько мелкий по объему? В этом сильно мало смысла.
PS: Даже если вы вдруг задумаете, скажем, пользовательские данные держать на больше партиции, то ничего невозможного нет. Возьмете большой жесткий диск с смонтируете его в /home.
. and always remember, it's not free tech support. Want some urgent help? Try to hire one or two. Konstantinus Posts: 99 Joined: Thu Apr 09, 2015 9:53 amPost by Konstantinus » Tue Feb 09, 2016 6:47 pm
Спасибо за совет.
А вот как со swap'om. Встречал советы размер оперативной памяти х 2. Но это звучит как-то глупо 12 гиг по своп?
skurudo VestaCP Team Posts: 8099 Joined: Fri Dec 26, 2014 2:23 pm Contact:Post by skurudo » Wed Feb 10, 2016 7:42 am
Konstantinus wrote: А вот как со swap'om. Встречал советы размер оперативной памяти х 2. Но это звучит как-то глупо 12 гиг по своп?Мне как-то сделали swap на 32 гига, чОтко по инструкции :)
В случае с мелкой ssd такой swap держать расточительно, я бы отдал под него 2-4 гига и успокоился. Уход в своп - уже нездоровая ситуация, к чему усугублять?
. and always remember, it's not free tech support. Want some urgent help? Try to hire one or two. raven-kg Posts: 9 Joined: Tue Feb 09, 2016 6:17 pmPost by raven-kg » Wed Feb 10, 2016 5:24 pm
В этой статье мы покажем, как использовать SSD диск в качестве кэширующего устройства для двух SATA дисков, объединенных в RAID 1 на сервере с CentOS Linux на примере LVM Cache. В такой конфигурации кэширующее и кэшируемое устройство должно входить в одну группу томов LVM, а отключение/включение кэша можно выполнять без на ходу без без перезагрузок и перемонтирования.
SSD-кэширование — технология, когда твердотельные SSD накопители используются в качестве буфера для часто запрашиваемых данных. Система определяет данные по степени “теплоты” и перемещает их на быстрый накопитель, используемый в качестве кэширующего диска. Кэш позволяется системе получать доступ к данным в несколько раз быстрее, чем если бы они были получены с более медленного жесткого диска.После установки ОС на RAID1 из двух SATA дисков, мы подключили отдельный SSD диск на 240 Гб. Проверим, что он доступен:
С помощью менеджера пакетов установите утилиту lvm2, которая будет использоваться для реализации кэша .
После установки ПО, нужно определить блочное устройство SSD-диска и раздел, к которому примонтирована нужная директория. В моем случае это будет директория home, раздел для которой я создал при установке ОС.
Директории /home соответствует раздел /dev/md126p2. Обратите на это внимание, так как дальнейшая настройка будет связана именно с этим разделом.
Теперь можно перейти к настройке кэша. Отмонтируйте директорию:
Для создания кэширующего SSD устройства выполните следующие команды
- pvcreate — инициализирует физический том для LVM
- vgcreate – создать группу томов
- lvcreate -l – создать логический том, размер тома указывается в процентах
- lvcreate -L – создание логического тома с метаданными для кэша
- lvconvert — объединяем кэш-пул и логический том через метаданные. Задаем режима кеширования, в нашем случае writeback.
Есть два режима кеширования:
Выбранный режим кэширования относится только к операциям записи. На скорость чтения данных с LVM тома с кэшем он не влияет.После выполнения всех настроек, можно проверить кэш на наличие ошибок:
Если ошибок нет, значит вы все сделали верно. Данная команда покажет процент использования кэша. На данный момент размер кэша будет чуть практически нулевой.
Теперь создадим файловую систему на новом LVM разделе:
После создания раздела, нужно определить его UUID, чтобы заменить его в fstab:
Заменяем в /etc/fstab
После замены UUID в fstab для нужного раздела, перезагрузите сервер и проверяем текущие настройки:
Чтобы узнать текущий режим работы SSD кэша, используйте команду:
Для смены режима, используются команды:
Если вам нужно заменить SSD диск, обязательно нужно удалить кэш:
После этого вы смело можете отключить сервер, заменить диске и добавить кэш заново с помощью следующих команд:
На этом работа по настройке SSD-кэширования окончена. Определить скорость работы ssd-кэша обычными утилитами для замера операций чтения/записи, невозможно. Скорость будет такая же как на обычном SATA диске, но это все из-за специфики работы кэша, как ранее мы описывали, он срабатывает именно для “горячих” данных. При тестировании работы в различных приложениях, повышение скорости действительно ощутимо, где-то в 3-4 раза.
Длительное использование SSD-хранилища (или твердотельного накопителя) приводит к снижению его производительности. Чтобы такое хранилище прослужило дольше, его работу нужно тщательно продумывать. Команда TRIM сообщает SSD, какие блоки данных больше не используются. Это позволяет внутренней системе SSD-накопителя выровнять износ устройства и подготовить его к дальнейшим операциям записи. TRIM может оказать существенное влияние на производительность и долговечность устройства.
В Linux можно настроить непрерывное выполнение TRIM, однако такая нагрузка может негативно сказаться на производительности. Существует также более мягкий альтернативный вариант – периодическое выполнение TRIM. При этом устройство получит все преимущества команды без ущерба для производительности.
Данное руководство поможет настроить периодический запуск TRIM на различных дистрибутивах Linux.
Как SSD-накопители хранят данные?
Чтобы лучше понимать, какие именно проблемы устраняет TRIM, нужно ознакомиться с особенностями хранения данных на SSD.
Ограничение циклов перезаписи
SSD-накопители могут записывать данные постранично, но они удаляют данные только на уровне блоков. Кроме того, данные записываются на страницы только после обнуления: то есть, перезаписать существующие данные напрямую невозможно.
Чтобы изменить данные, SSD-накопитель должен прочитать их старую версию, отредактировать её в памяти, а затем записать обновлённые данные на новую – обнулённую – страницу. После этого устройство обновляет внутреннюю таблицу и задаёт новое местонахождение данных. Предыдущее местонахождение данных становится устаревшим – оно больше не используется, но еще не обнулено.
Восстановление устаревших страниц
Чтобы восстановить устаревшие страницы, внутренние процессы сборщика мусора SSD должны прочитать все действительные страницы из блока и записать их в новый блок. После этого снова обновляется внутренняя таблица. Старый блок, который в настоящее время не содержит никаких уникальных и востребованных данных, можно обнулить и использовать для дальнейшей записи.
Как работает TRIM?
Процессы сборщика мусора SSD отвечают за удаление блоков и выравнивание износа устройства. Однако файловые системы, как правило, удаляют данные, просто отмечая занятое ими пространство как доступное для записи пространство. На самом деле они не удаляет данные из базового хранилища, а просто позволяют перезаписать ранее занятую область памяти.
Это означает, что SSD-накопитель обычно не знает, что страница больше не нужна, пока файловая система не использует это логическое местоположение для записи новых данных. Накопитель не может выполнять процедуру сборки мусора, потому что ему просто не сообщили об удалении данных, он узнаёт об этом только тогда, когда ранее занятое пространство используется для записи других данных.
Команда TRIM уведомляет SSD-устройство о блоках данных, которые больше не содержатся в файловой системе. Благодаря этому накопитель может своевременно выполнить сборку мусора и обнулить страницы, чтобы использовать их в дальнейшем. SSD может очистить устаревшие страницы и поддерживать себя в хорошем рабочем состоянии.
Как говорилось ранее, запуск TRIM после каждой операции удаления данных может негативно повлиять на производительность устройства. Потому рекомендуется распланировать запуск команды TRIM, что позволит ей передавать SSD-устройству общую информацию обо всех ненужных страницах.
Отключение непрерывного выполнения TRIM
Если вы уже настроили непрерывное выполнение команды TRIM на смонтированном устройстве, отключите команду, чтобы настроить её периодический запуск.
Непрерывное выполнение команды включается с помощью опции discard при монтировании устройства или раздела.
Найдите текущую файловую систему, смонтированную с опцией discard.
Перемонтируйте эти файловые системы, убрав опцию discard. Для этого используйте команду mount и опцию -o remount,nodiscard:
Снова запустите команду findmnt, теперь она должна не вернуть никакого вывода:
findmnt -O discard
Откройте файл /etc/fstab, чтобы просмотреть текущие опции монтирования файловой системы. Этот файл определяет, как монтируется файловая система при запуске сервера.
sudo nano /etc/fstab
Найдите в нём опцию discard и удалите её:
Сохраните и закройте файл. Теперь при повторном монтировании файловой системы опция discard не будет использоваться.
Настройка TRIM в дистрибутивах systemd
В данном разделе показано, как настроить периодический запуск TRIM в дистрибутивах, которые используют систему инициализации systemd.
Ubuntu 16.04
Дистрибутив Ubuntu 16.04 предоставляет сценарий, который еженедельно запускается с помощью cron.
Примечание: Стратегия настройки TRIM в Ubuntu 16.04 не зависит от systemd и отличается от остальных дистрибутивов этого типа.
Чтобы просмотреть сценарий, введите:
Как видите, сценарий требует версии fstrim с флагом –all. Многие версии fstrim, поставляющиеся в ранних версиях Ubuntu, не поддерживают этого флага.
Другие дистрибутивы systemd
В остальных дистрибутивах на основе systemd поддержка TRIM включается в файле fstrim.timer, который запускает операции TRIM на всех доступных смонтированных устройствах один раз в неделю. Он тоже использует опцию fstrim —all.
На момент написания этого руководства к таким дистрибутивам относятся:
- Debian 8
- CentOS 7
- Fedora 24
- Fedora 23
- CoreOS
В CentOS 7, Fedora 23, Fedora 24 и CoreOS юниты fstrim.service и fstrim.timer доступны по умолчанию. Чтобы настроить еженедельный запуск TRIM на всех смонтированных накопителях, включите юнит .timer:
sudo systemctl enable fstrim.timer
В Debian 8 юниты fstrim.service и fstrim.timer доступны внутри файловой системы, но по умолчанию не загружены в systemd. Сначала просто скопируйте эти файлы:
sudo cp /usr/share/doc/util-linux/examples/fstrim.service /etc/systemd/system
sudo cp /usr/share/doc/util-linux/examples/fstrim.timer /etc/systemd/system
Затем вы можете активировать этот юнит так же, как и в других дистрибутивах.
sudo systemctl enable fstrim.timer
Теперь команда TRIM будет выполняться на всех доступных устройствах раз в неделю.
Настройка TRIM в других дистрибутивах
Большинство дистрибутивов, которые используют не Systemd, а другую систему инициализации, также поставляются с fstrim без флага —all. Это несколько усложняет автозапуск TRIM.
Важно! Использовать TRIM на устройствах, которые не поддерживают эту команду или выполняют её не правильно, очень опасно и может привести к потере данных. Флаг —all может обеспечить безопасное выполнение команды, однако не пытайтесь определить вручную, корректно ли поддерживают подключенные диски данную операцию.
В системе Ubuntu 14.04 существует короткий сценарий fstrim-all, который еженедельно выполняется демоном cron. Однако данный сценарий не всегда правильно интерпретирует поддержку TRIM на подключенных дисках.
Существует обходное решение для этого и других дистрибутивов с поддержкой fstrim без флага —all: нужно скомпилировать статически скомпонованную версию fstrim с поддержкой этого флага. Эту версию можно установить и явно вызывать с помощью cron.
Такой вариант лучше всего сработает в:
- Ubuntu 14.04
- Ubuntu 12.04
- Debian 7
- CentOS 6
В Ubuntu 14.04 нужно сначала отключить сценарий fstrim-all, поскольку он не может корректно определять статус.
sudo chmod a-x /etc/cron.weekly/fstrim
sudo mv /etc/cron.weekly/fstrim /etc/cron.weekly/fstrim.bak
Установка инструментов для компиляции
Установите набор инструментов для сборки программ.
В Ubuntu и Debian:
sudo apt-get update
sudo apt-get install build-essential
В CentOS:
sudo yum groupinstall 'Development Tools'
Загрузка и извлечение исходного кода
Утилита fstrim поставляется в наборе инструментов util-linux. Исходный код можно найти здесь.
Выберите самую новую версию пакета. На момент написания руководства это v2.28.
Откройте каталог и найдите самый новый архив (его название должно начинаться с util-linux- и заканчиваться расширением .tar.gz). На данный момент наиболее актуальным является util-linux-2.28.1.tar.gz. Кликните правой кнопкой и скопируйте ссылку в буфер обмена.
Вернитесь на сервер и откройте каталог /tmp. С помощью утилиты curl или wget загрузите необходимый файл.
tar xzvf util-linux*
Теперь исходный код можно скомпилировать.
Настройка и компиляция исходного кода
Откройте извлечённый каталог:
Теперь нужно настроить программное обеспечение. Создайте бинарный файл для fstrim.
Для этого необходимо включить статические ссылки и отключить расшаренные библиотеки. Введите:
./configure --enable-static --disable-shared
Чтобы скомпилировать утилиту fstrim, введите:
Скопируйте бинарный файл в каталог, который не указан в PATH. Этот файл будет вызываться только демоном cron, потому нужно убедиться, что он не будет конфликтовать со стандартной утилитой fstrim.
Создайте каталог /cron-bin и переместите в него бинарный файл:
sudo mkdir /cron-bin
sudo cp /tmp/util-linux*/fstrim /cron-bin
Теперь у вас есть доступ к пользовательской версии утилиты fstrim.
Настройка cron
Теперь нужно создать новый сценарий, который будет запускаться демоном cron.
Это делается почти так же, как в Ubuntu 16.04 (нужно также указать место хранения бинарного файла).
sudo nano /etc/cron.weekly/fstrim
Вставьте в него следующие строки. Это включит поддержку флага —all:
Сохраните и закройте файл.
Сделайте сценарий исполняемым.
sudo chmod a+x /etc/cron.weekly/fstrim
Демоны cron и anacron смогут использовать этот сценарий для выполнения проверки TRIM.
Заключение
Теперь сервер Linux запускает TRIM раз в неделю. Команда TRIM увеличивает производительность и уменьшает износ SSD-устройств.
Привет, Хабр! Представляю вашему вниманию русскоязычную версию статьи "Migrating CentOS system from HDD to smaller SSD on XFS filesystem" автора Denis Savenko.
Данная статья является русскоязычной версией ранее мной же опубликованной статьи на английском языке с небольшими корректировками на аудиторию. Сразу оговорюсь — я не являюсь маньяком линукса или даже профессиональным системным администратором, поэтому вполне вероятно, что порой я мог использовать необычные, или даже глупые решения. Я буду очень благодарен вам, если вы укажете мне на них в комментариях, чтобы я мог улучшить данное руководство вместо того, чтобы просто заминусовать статью. Заранее вас за это благодарю.
Я думаю я не один, кто в какой-то момент решил преобрести себе SSD-диск для работающей системы. В моём случае это была работающая система на CentOS 7 на моём крошечном домашнем сервере. Далее я хотел перенести её "как есть" на новый диск. Но, как оказалось, это не так то просто сделать, учитывая следующее:
- Новый SSD диск был гораздо меньшего объёма, чем уже установленный HDD (серьёзно, SSD всё ещё весьма дорог по сравнению с дисковыми накопителями).
- Разделы на прежнем диске были отформатированы в файловой системе xfs . Это и не удивительно, учитывая тот факт, что CentOS, начиная с 7-ой версии предлагает эту файловую систему "по умолчанию" (наряду и с другими системами на основе RHEL, такими как, собственно, Red Hat Enterprise Linux 7, Oracle Linux 7 или Scientific Linux 7).
- Работающая система должна остаться без изменений, включая конфигурацию, установленное ПО, права доступа и прочие атрибуты файловой системы.
Позвольте мне пояснить, почему описанные мной выше вещи являются серьёзными усложнениями поставленной перед нами задачи.
Затем, если бы использовалась файловая система, отличная от xfs , например, достаточно популярная ext4 , можно было бы "сжать" старый раздел диска до размеров нового диска. Затем выполняются какие либо действия из описанных выше и вы в дамках. Однако, изменение размера разделов в сторону уменьшения на xfs невозможно в силу её реализации — вы можете только увеличить разделы при её использовании.
И последнее, но ничуть не менее важное, если бы перед нами не стояло задачи перенести работающую сконфигурированную систему с сохранением всех метаданных, было бы проще просто установить систему с нуля на новый диск, заранее сохранив пару важных файлов. Это не подходило мне по двум причинам — во-первых волосы становились дыбом при мысли, что мне придётся повторить все те же действия, которые я выполнял на протяжении нескольких дней кряду, а во-вторых — это просто не спортивно. Я был уверен, что при должном понимании технических особенностей, перенос работающей системы на другой диск не должен был быть невыполнимой задачей.
Тем не менее, я выработал и оттестировал как минимум на двух различных окружениях подробный пошаговый план переноса работающей системы, берущий во внимание все вышеописанные ограничения.
Этап 1. Подготовка
Вот список того, что нам потребуется для переноса:
Этап 2. Миграция
Глотнём кофе и приступим к процессу переноса с запуска системы с подготовленного Live CD дистрибутива. Затем откройте терминал и перейдите в режим суперпользователя при помощи команды su -
Далее в данном руководстве предполагается, что все команды выполняются от имени суперпользователя ( root )
Шаг 1. Разрешение удалённого доступа (опционально)
Для меня удобнее иметь удалённый доступ к машине, на которой я буду производить перенос, т.к. я имею возможность просто копипастить заранее подготовленные команды в свой PuTTY терминал. Если вы загрузили это руководство в браузере на целевой машине, смело переходите к следующему шагу — всё, здесь описанное, вам не понадобится.
Для того, чтобы разрешить удалённый доступ, необходимо задать пароль для пользователя root и запустить SSH демон:
Теперь можно подключиться к целевой машине вашим SSH клиентом (например, PuTTY).
Шаг 2. Разбивка диска на разделы
Вы можете использовать вашу любимую утилиту для этого. Например, в Gnome есть предустановленная утилита для управления дисками. Также в интернетах хвалят gparted , однако я намеренно использовал fdisk , т.к, например, gparted просто не распознавал мой NVMe SSD-диск.
Диск следует разбить по образу и подобию прежнего диска. Я не маньяк партиционирования, поэтому моя схема партиционирования была стандартной:
- /boot — стандартный раздел размером 1GB;
- swap раздел размером 4G;
- / — корневой раздел, LVM volume group с наименованием "main", занимающий оставшееся пространство на диске.
Итак, приступим к разбивке нового диска:
Раздел /boot должен быть стандартным линукс-разделом, поэтому сразу создаём файловую систему на нём:
И теперь нам необходимо создать LVM-структуру для второго раздела на диске. Назовём новую LVM-группу newmain (впоследствии переименуем):
Теперь мы готовы к созданию файловой системы на новых логических разделах:
Шаг 3. Активная фаза
Прежде чем мы начнём, сделаем обе LVM-группы активными (т.к. мы работаем из под Live CD):
Создадим директории для точек монтирования, и примонтируем к системе старые и новые разделы наших дисков:
Убедимся, что всё в порядке при помощи команды lsblk :
Если вы видите что-то наподобие этого, вы всё сделали верно. И здесь начинается настоящая магия — мы собираемся использовать xfsdump для миграции наших данных. Эта утилита достаточно умная и знает о внутреннем устройстве файловой системы xfs , что позволяет ей копировать только занятые данными блоки, что, в свою очередь, во-первых позволяет нам копировать данные на диск меньшего размера, а во-вторых сильно ускоряет процесс переноса. Итак, давайте сделаем дамп данных при помощи этой утилиты, и на лету развернём эти данные на новом месте:
Пару слов об использованных флагах:
- -J уменьшает размер фидбека;
- - сообщает xfsdump и xfsrestore использовать стандартные потоки stdout и stdin соответственно вместо файлов.
Эта процедура может занять некоторое время (зависит от объёма ваших данных). Поэтому здесь вам пригодится приготовленная заранее чашка кофе, которую самое время выпить, а то остынет.
Шаг 4. Делаем новый диск загрузочным
Первое, что нужно сделать, это узнать UUID для старого и нового загрузочных разделов ( /boot ) при помощи команды blkid :
Предполагая, что sda1 — прежний раздел \boot , и nvme0n1p1 — новый, производим замену UUID в конфигурационных файлах на новой точке монтирования:
Эти две команды подготовят ваши системные файлы конфигурации к новому диску.
Теперь самое время переименовать LVM-группы и отмонтировать диски:
Единственное, что осталось сделать, это переустановить загрузчик. Это необходимо делать с использованием chroot :
Шаг 5. Последний штрих
На данном этапе все данные уже должны быть перенесены и новый диск должен стать загрузочным. Нужно только перезапуститься, вынуть Live CD из привода, и выбрать новый диск в BIOS для загрузки:
Если что-то пошло не так и система не загружается, вы всегда можете "откатиться" на старый диск, просто запустившись с Live CD повторно и переименовав LVM-группы обратно, выполнив vgrename -v main и vgrename -v main , и затем снова перезапуститься.
На этом обязательная часть программы окончена и мы успешно перенесли работающую систему на новый диск. Старый диск можно извлекать из компьютера.
Использование старого HDD в качестве медиа-хранилища
Если вы, как и я, после переноса системы, хотите использовать ваш прежний диск как медиа-хранилище, это делается также легко.
Во-первых, переразбейте прежний диск
Мы не станем создавать файловую систему на диске напрямую. Вместо этого мы создадим новую LVM-группу, в которую добавим этот диск. Это позволит нам в будущем легко добавлять новые диски в эту группу без лишней мороки (логический диск при этом останется прежний):
Для того, чтобы сохранить изменения после перезагрузки системы, следует также добавить запись о точке монтирования в /etc/fstab :
Готово!
Теперь можно утверждать, что мы успешно перенесли работающую на xfs систему на новый диск меньшего размера. Как бонус, мы начали использовать прежний диск в качестве медиа-хранилища.
UPDATE 02.04.2018
Так как мы производили перенос системы на SSD, то, как советуют в комментариях, хорошо бы уже после переноса в работающей системе включить периодическое исполнение команды trim (сборщик мусора для SSD-дисков, который позволяет не терять в производительности через время). Для этого необходимо выполнить команду:
Это включит на новой системе исполнение trim раз в неделю на любой systemd системе. В случае, если вы или ваша система не используете systemd , есть исчерпывающее руководство от DigitalOcean на почти любой случай.
Пожалуйста, оставляйте ваши комментарии, если нашли ошибку или знаете способ лучше как выполнить те или иные действия. Надеюсь, данная инструкция окажется вам полезной!
Программный RAID проще и безопаснее, т. к. если что-то выйдет из строя, то RAID достаточно просто восстановить, а если выйдет из строя аппаратный RAID контроллер, то проблем будет больше.
Выбор дисков для RAID массивов
Для отображения подключенных дисков выполним команду:
Создание RAID1 массива
Выполним следующие команды для создания массивов для БД и логов:
На вопрос Continue creating array? отвечаем y.
Проверим результат выполнения команд:
Настройка RAID массивов
Разметим пространство. В качестве файловой системы выберем ext4:
Создадим конфигурационный файл для утилиты mdadm:
Монтируем созданные RAID массивы в каталог /raid:
Для автоматического монтирования RAID массивов при загрузке системы выполним команду:
в открывшемся файле добавим строчки:
/dev/md0 /raid200 ext4 defaults 1 2
/dev/md1 /raid120 ext4 defaults 1 2
Примеры использования mdadm
Пометка диска как сбойного
Удаление сбойного диска
Добавление нового диска
Сборка существующего массива
Расширение массива
Проверяем, что диск (раздел) добавился:
Если раздел действительно добавился, мы можем расширить массив:
Рекомендуется задать файл бэкапа на случай прерывания перестроения массива, например добавить:
При необходимости, можно регулировать скорость процесса расширения массива, указав нужное значение в файлах
Убедитесь, что массив расширился:
Нужно обновить конфигурационный файл с учётом сделанных изменений:
Переименование массива
Для начала отмонтируйте и остановите массив:
Затем необходимо пересобрать как md5 каждый из разделов sd[abcdefghijk]1
Удаление массива
Для начала отмонтируйте и остановите массив:
Затем необходимо затереть superblock каждого из составляющих массива:
Если действие выше не помогло, то затираем так:
Заключение
В итоге мы получили два программных RAID массива уровня 1, которые будем использовать для баз данных 1С:Предприятие 8.3
Читайте также: