Увеличение емкости хранилища

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

В этой статье

Процесс выделения новых системных ресурсов зависит от платформы виртуализации и типа ресурсов. Всегда следует настраивать мониторинг и оповещение ключевых системных ресурсов. Дополнительные сведения см. в разделе Мониторинг экземпляра.

По мере того как присоединяется ваш экземпляр GitHub Enterprise Serverбольше пользователей, возможно, придётся изменить размер объёма памяти. Сведения об изменении размера хранилища см. в документации по платформе виртуализации.

Требования и рекомендации

Примечание.

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

Предупреждение

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

Лицензии пользователейВиртуальные ЦП x86-64ПамятьКорневое хранилищеПодключенное хранилище (данные)ОПЕРАЦИЙ ВВОДА-ВЫВОДА
Пробная версия, демонстрационная версия или 10 облегченных пользователей432 Гб400 ГБ500 ГБ600
До 1000848 ГБ400 ГБ500 ГБ3000
1000 до 30001664 ГБ400 ГБ1000 ГБ6000
От 3000 до 500032128 ГБ400 ГБ1500 ГБ9000
5 000 до 8 00048256 ГБ400 ГБ3000 ГБ12 000
от 8000 до 10000 и выше64512 ГБ400 ГБ5000 ГБ15000

Корневое хранилище ссылается на общий размер корневого диска экземпляра. Доступное пространство на корневая файловая система составляет 50 % общего объема хранилища, доступного на корневом диске. Дополнительные сведения см. в разделе Обзор системы.

Увеличение размера секции данных

  1. Измените размер существующего диска для тома пользователя с помощью средств платформы виртуализации.

  2. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

    Shell
    ssh -p 122 admin@HOSTNAME

  3. Поместите устройство в режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.

  4. Перезагрузите устройство, чтобы обнаружить выделение нового хранилища:

    sudo reboot

  5. Выполните команду ghe-storage-extend, чтобы развернуть файловую систему /data/user:

    ghe-storage-extend

  6. Убедитесь, что системные службы работают правильно, а затем выпустите режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.

Предупреждение

ghe-storage-extend Если команда (или предыдущая автоматическая проверка) сообщает: ghe_user_data contains a file system with errors, необходимо восстановить файловую систему перед повторной попыткой изменения размера. Не запускайте ghe-storage-extend повторно до тех пор, пока проверка не завершится чисто. Инструкции по восстановлению см. в разделе Исправление ошибок файловой системы.

Исправление ошибок файловой системы

Если проверка файловой системы не удалась во время ghe-storage-extend, выполните следующие действия, чтобы восстановить ее.

Убедитесь, что устройство находится в режиме обслуживания и не выполняются фоновые задания:

Shell
ghe-maintenance -s
ghe-resque-info

  1. Остановите и активируйте пользовательский том, затем запустите принудительную проверку файловой системы (автоответ «да»):

    Shell
    sudo systemctl stop ghe-user-disk
VGNAME=$(sudo lvs --noheadings -o vg_name | grep ghe_storage_ | awk '{ print $1 }')
sudo vgchange -ay "$VGNAME"
sudo vgscan --mknodes
sudo fsck -fy /dev/mapper/${VGNAME}-ghe_user_data

  2. Повторите попытку изменить размер:

    Shell
    ghe-storage-extend

  3. Перемонтируйте и проверьте новый размер:

    Shell
    sudo systemctl start ghe-user-disk
df -h /data/user

  4. Перезагрузите и подтвердите:

    Shell
    sudo reboot
df -h /data/user

Увеличение размера корневой секции с помощью нового устройства

  1. Настройте новый GitHub Enterprise Server экземпляр с большим корневым диском, используя ту же версию, что и ваше текущее устройство. Дополнительные сведения см. в разделе Настройка экземпляра GitHub Enterprise Server.

  2. Завершите работу текущего устройства:

    sudo poweroff

  3. Отключите диск данных от текущего устройства с помощью средств платформы виртуализации.

  4. Подключите диск данных к новому устройству с корневым диском большего объема.

Увеличение размера корневой секции с помощью нового устройства

Предупреждение

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

  1. Подключите новый диск с требуемым размером к устройству GitHub Enterprise Server .

  2. Выполните команду lsblk, чтобы определить имя устройства нового диска.

  3. Прежде чем продолжить, определите, имеет ли устройство глобально уникальную таблицу секционирования (gptGUID) или таблицу секционирования основной загрузочной записи (dosMBR). Тип таблицы секций зависит от того, как корневой диск устройства был подготовлен, а не от версии GitHub Enterprise Serverвыпуска, поэтому всегда проверяйте его непосредственно, а не предполагая, что он основан на версии.

    Чтобы проверить тип таблицы секции, выполните следующую команду. Результат будет либо gpt``dos.

    sudo lsblk -no pttype $(findmnt -no source /)

Увеличение размера корневой секции в таблице секций GUID

  1. Создайте резервную копию существующей секции загрузки EFI:

    sudo dd if=/dev/disk/by-label/EFIBOOT of=EFIBOOT.bak bs=1M

  2. Выполните команду parted, чтобы отформатировать диск, изменив имя устройства на /dev/xvdg.

    sudo parted /dev/xvdg mklabel gpt
sudo parted -a optimal /dev/xvdg mkpart bios fat32 1MiB 2MiB
sudo parted /dev/xvdg set 1 bios_grub on
sudo parted -a optimal /dev/xvdg mkpart efi fat32 2MiB 512MiB
sudo parted /dev/xvdg set 2 esp on
sudo parted -a optimal /dev/xvdg mkpart primary 512MiB 50%
sudo parted /dev/xvdg set 3 boot off
sudo parted /dev/xvdg set 3 esp off
sudo parted -a optimal /dev/xvdg mkpart primary 50% 100%

  3. Если устройство настроено для высокой доступности или георепликации, чтобы остановить репликацию, выполните ghe-repl-stop команду на каждом узле реплики:

    ghe-repl-stop

  4. Чтобы установить GitHub Enterprise Server программное обеспечение на новый разбитый диск, выполните команду ghe-upgrade . Вам нужно заменить PACKAGE-NAME.pkg на путь к платформенному пакету обновления, который соответствует версии, GitHub Enterprise Server уже запущенной на устройстве. Не удается использовать универсальный пакет обновления горячего исправления, например github-enterprise-2.11.9.hpkg. После выполнения команды ghe-upgrade службы приложений будут автоматически завершены.

    ghe-upgrade PACKAGE-NAME.pkg -s -t /dev/xvdg3

  5. Выполните следующие команды на дополнительных секциях только что добавленного диска:

    sudo dd if=/dev/disk/by-label/EFIBOOT of=/dev/xvdg2 bs=1M
sudo mkfs.ext4 -L fallback /dev/xvdg4

  6. Завершение работы приложения:

    sudo poweroff

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

  8. Запустите устройство.

  9. Убедитесь, что системные службы работают правильно, а затем выпустите режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.

Если устройство настроено для высокого уровня доступности или георепликации, не забудьте запустить репликацию на каждом узле реплики, используя ghe-repl-start после обновления хранилища на всех узлах.

Увеличение размера корневой секции в таблице секций MBR

  1. Выполните команду parted, чтобы отформатировать диск, изменив имя устройства на /dev/xvdg.

    sudo parted /dev/xvdg mklabel msdos
sudo parted /dev/xvdg mkpart primary ext4 0% 50%
sudo parted /dev/xvdg mkpart primary ext4 50% 100%

  2. Если устройство настроено для высокой доступности или георепликации, чтобы остановить репликацию, выполните ghe-repl-stop команду на каждом узле реплики:

    ghe-repl-stop

  3. Чтобы установить GitHub Enterprise Server программное обеспечение на новый разбитый диск, выполните команду ghe-upgrade . Вам нужно заменить PACKAGE-NAME.pkg на путь к платформенному пакету обновления, который соответствует версии, GitHub Enterprise Server уже запущенной на устройстве. Не удается использовать универсальный пакет обновления горячего исправления, например github-enterprise-2.11.9.hpkg. После выполнения команды ghe-upgrade службы приложений будут автоматически завершены.

    ghe-upgrade PACKAGE-NAME.pkg -s -t /dev/xvdg1

  4. Выполните команду на вторичной секции только что добавленного диска:

    sudo mkfs.ext4 -L fallback /dev/xvdg2

  5. Завершение работы приложения:

    sudo poweroff

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

  7. Запустите устройство.

  8. Убедитесь, что системные службы работают правильно, а затем выпустите режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.

Если устройство настроено для высокого уровня доступности или георепликации, не забудьте запустить репликацию на каждом узле реплики, используя ghe-repl-start после обновления хранилища на всех узлах.