Подключение и проверка дисков

Подключение к серверу начинается с записи о его передаче

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

Запись об оплате не подтверждает готовность сервера. Подключение выполняется после подготовки сервера по данным из его карточки.

Linux
SSH
Windows Server
RDP
Адрес для управления
Первый IPv4
Сначала проверка, затем подключение

Запись о передаче — отправная точка для подключения

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

  1. 01

    Убедитесь, что выбран нужный сервер

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

  2. 02

    Проверьте все параметры доступа

    В сведениях о сервере указаны IP-адрес, учётная запись, пароль и другие доступные параметры подключения. Не следует угадывать порт или имя пользователя по распространённым значениям по умолчанию: универсальной учётной записи и фиксированного порта нет, фактические параметры указаны в данных о передаче.

  3. 03

    Выберите клиент для установленной системы

    Для Linux, FreeBSD и Proxmox VE используется SSH, для Windows Server — RDP. Следует проверить сохранённые в клиенте старые адреса, учётные записи и пароли. Если передача сервера ещё не завершена, сначала проверьте его статус и не повторяйте попытки с непроверенными параметрами.

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

Linux и Unix-подобные системы

При первом входе по SSH проверьте подлинность узла

Для AlmaLinux, CentOS Stream, Debian, Ubuntu Server, FreeBSD и Proxmox VE используется SSH. Способ администрирования зависит от системы, но параметры подключения берутся из одной записи о передаче сервера.

Первое подключение

В локальном SSH-клиенте указываются первый IPv4-адрес, учётная запись из данных о передаче и фактический порт. Для входа используется указанная там же схема аутентификации. При первом подключении появляется запрос на подтверждение подлинности узла: необходимо сверить целевой сервер и доступные сведения о его подлинности, а не принимать запрос автоматически.

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

Проверьте новую аутентификацию до закрытия старого сеанса

После первого входа рекомендуется сменить пароль и настроить SSH-ключи с учётом учётных записей и прав выбранной системы. Закрытый ключ хранится на компьютере администратора, а открытый ключ добавляется в авторизованные ключи целевой учётной записи. Открытый и закрытый ключи нельзя использовать вместо друг друга.

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

Команды проверки дисков для Linux не следует применять в FreeBSD. SSH обеспечивает подключение, а операции с хранилищем и правами доступа выполняются средствами соответствующей системы.

Windows Server

Для сеанса RDP используются данные учётной записи из передачи

К серверам с Windows Server подключаются по протоколу удалённого рабочего стола RDP. Для сеанса используется локальный клиент удалённого рабочего стола, первый IPv4-адрес из панели управления и соответствующие учётные данные. Сохранённые данные для входа на другой сервер использовать не следует.

  1. 01

    Проверьте сервер и учётную запись

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

  2. 02

    Проверьте ввод и язык системы

    При ошибке ввода пароля сначала проверьте раскладку клавиатуры, регистр и пробелы, случайно скопированные вместе с паролем. Язык интерфейса Windows Server может быть английским, традиционным или упрощённым китайским. Он не меняет учётную запись, указанную при передаче, и правило подключения по первому IPv4-адресу.

  3. 03

    Сохраните возможность восстановить доступ

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

Назначение адресов

Для удалённого управления используется первый IPv4-адрес

Если серверу выделено несколько IPv4-адресов, для SSH и RDP используется первый адрес в списке. Остальные адреса предназначены для служб или планирования виртуальных машин внутри системы. Их наличие в списке передачи само по себе не означает, что они являются адресами для входа в панель управления сервером.

Сначала распределяются адреса, затем настраиваются система и привязка служб.
Назначение адресаИспользованиеПроверка перед настройкой
Первый IPv4Удалённое управление по SSH или RDPСверить адрес с карточкой сервера и использовать его учётные данные и параметры аутентификации.
Остальные IPv4Самостоятельная привязка к службам или виртуальным машинам внутри системыПроверить распределение адресов, сетевые настройки системы и прослушивание портов служб, чтобы избежать повторной привязки.

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

Проверка хранилища при первом входе

Два отдельных NVMe: сначала проверка, затем пул

В стандартную комплектацию выделенных серверов AMD входят 2 × 1 ТБ NVMe с прямым подключением каждого накопителя и без аппаратного RAID. Успешный вход в систему подтверждает только наличие канала управления. Перед запуском файлового хранилища необходимо также проверить диски, занятое системой место и выбранный уровень отказоустойчивости.

Сначала сопоставьте диски и их назначение

Зафиксируйте идентификаторы дисков, ёмкость, существующие разделы и точки монтирования; отдельно отметьте устройство с системой и устройство, предназначенное для данных. Если выбрана установка дополнительных дисков, внесите их в список отдельно и не определяйте физическое расположение накопителя только по порядку перечисления устройств.

Следующие команды предназначены для Linux и только отображают сведения о блочных устройствах и файловых системах — они не создают массивы и не форматируют диски. Названия устройств следует сверять с фактическим выводом. В FreeBSD применяются собственные средства проверки устройств и хранилища.

Linux · проверка без изменений

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
findmnt

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

Раздельное использование: ёмкость и отказоустойчивость

Суммарная заявленная необработанная ёмкость двух дисков по 1 ТБ составляет 2 ТБ, но это не равно доступному объёму файловой системы. Разметка, место под систему и форматирование влияют на доступную ёмкость. Данные на одном диске не получают автоматическую копию только потому, что установлен второй диск.

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

Зеркало: отказоустойчивость и резервные копии — отдельно

При создании зеркала ZFS или программного зеркала из двух дисков по 1 ТБ для планирования следует учитывать примерно половину заявленной ёмкости. Фактически доступное место также зависит от системы и накладных расходов файловой системы. Перед созданием пула следует определить, куда будут перенесены данные; при наличии разделов сначала необходимо перенести их содержимое.

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

Задачу резервного копирования следует включать после подготовки хранилища: необходимо определить исходные каталоги, место назначения, срок хранения и способ аутентификации, а затем проверить передачу и восстановление на небольшом объёме данных. Статус «выполнено» сам по себе не подтверждает возможность восстановления — необходимо проверить содержимое и права доступа восстановленных файлов.

Поиск причины по уровням

При сбое подключения проверьте адрес, аутентификацию и сеть

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

  1. 01

    Проверьте статус передачи и первый адрес

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

  2. 02

    Отличите ошибку входа от отсутствия соединения

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

  3. 03

    Проверьте сетевые правила на обеих сторонах

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

  4. 04

    Опишите воспроизводимую проблему в заявке

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

Восстановление после ошибки настройки

Аварийный доступ не заменяет обычное удалённое управление

Если допущена ошибка в настройках сети или аутентификации, графический сеанс в браузере панели управления предназначен только для аварийного восстановления. Он не является общедоступным способом подключения; для обычного управления используются SSH или RDP.

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

Подключение к DGX Spark

Для управления DGX OS используется SSH

Учётные данные DGX Spark также доступны в панели управления OnuCloud. В карточке соответствующего сервера указаны адрес и учётная запись для подключения по SSH к DGX OS. Инструкции по выбору системы и настройке дисков для выделенных серверов AMD к нему неприменимы.

Параметры подключения — в карточке сервера

Для подключения используются адрес и данные аутентификации из карточки сервера; значения по умолчанию угадывать не следует. После первого входа необходимо проверить работу SSH-сеанса и права учётной записи, а затем при необходимости настроить ключи или брандмауэр. После изменения настроек исходный сеанс следует оставить открытым и проверить аутентификацию в новом подключении.

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

Аппаратная перезагрузка и переустановка — через заявку

В DGX Spark нет BMC / IPMI. Для аппаратной перезагрузки или переустановки системы необходимо отправить заявку через панель управления, указав идентификатор сервера, описание проблемы и выполненные действия. Методы внеполосного управления для оборудования другого типа здесь неприменимы.

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

Продолжайте работу с карточки нужного сервера

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