Российские СХД для баз данных и хранения резервных копий: модели и критерии выбора

Для размещения баз данных и хранения резервных копий к СХД предъявляют разные требования. Разберем, какие характеристики учитывать при выборе, рассмотрим подходящие модели российских производителей и объясним, что проверить перед закупкой.

Чем отличаются требования к СХД для баз данных и резервных копий

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

Особенности хранения рабочих баз данных

Представим компанию, где сотрудники одновременно работают в 1С. Одни проводят документы, другие изменяют записи или формируют отчеты. Приложение отправляет запросы к базе данных, а система управления базами данных (СУБД) обрабатывает их. Для выполнения части операций сервер читает информацию с накопителей или записывает изменения.

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

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

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

Особенности хранения резервных копий

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

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

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

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

Можно ли использовать одну СХД для обеих задач

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

У такого подхода есть два ограничения.

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

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

Поэтому для восстановления после полного отказа основной СХД необходимо хранить резервные копии за ее пределами, на независимом оборудовании или в другом месте.

СХД для рабочих данных и резервных копий

Выбрать СХД →

Важно!

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

Какие параметры учитывать при выборе СХД

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

Производительность: IOPS, задержки и пропускная способность

У СХД есть три основных показателя производительности. Они описывают разные стороны работы дисковой подсистемы:

• IOPS — количество операций чтения и записи за секунду. По нему оценивают, сколько запросов на обращение к дискам может обработать система.
• Задержка — время выполнения одной операции чтения или записи. Обычно измеряется в миллисекундах. Чем дольше обрабатывается запрос, тем больше времени приложение может тратить на ожидание данных.
• Пропускная способность — объем информации, который хранилище передает за секунду. Измеряется в МБ/с или ГБ/с.

При сравнении оборудования важно учитывать все три значения. 

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

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

— Редакция CRABBIT

Например, во время массового формирования отчетов или обработки большого количества операций в учетной системе.

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

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

Полезная емкость и запас на расширение

Суммарная емкость установленных накопителей еще не показывает, сколько информации можно разместить на СХД. Часть пространства может использоваться для защиты от отказа дисков и внутренних нужд системы.

Например, при применении RAID с избыточностью часть общей емкости расходуется на хранение дополнительных данных, необходимых для сохранения доступности информации при неисправности накопителя. Размер таких расходов зависит от выбранной схемы защиты.

Для расчета потребности в дисковом пространстве понадобятся следующие сведения:

• Текущий объем данных. Сколько места занимают базы, рабочие файлы и другая информация.
• Темпы роста. Как увеличивается объем за месяц или год.
• Срок хранения копий. Как долго требуется сохранять предыдущие версии информации.
• Объем изменений. Сколько новых или измененных данных появляется между сеансами резервного копирования.
• Запас свободного пространства. Сколько места потребуется для дальнейшего роста и служебных операций.

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

Однако заранее закладывать определенный коэффициент сжатия без проверки нельзя. Результат зависит от состава информации и используемого программного обеспечения.

Важно!

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

Скорость резервного копирования и восстановления

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

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

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

Для восстановления необходимо определить еще два показателя:

• Допустимая потеря данных (RPO). Максимальный период, за который организация готова потерять изменения после аварии. Например, при допустимой потере данных за один час система защиты должна обеспечивать возможность восстановления с соответствующей давностью.
• Допустимое время восстановления (RTO). Срок, за который приложение или сервис должен вернуться к работе после сбоя.

Оба показателя задают исходя из требований компании. При этом RPO влияет на частоту создания точек восстановления, а RTO помогает определить необходимую скорость и способ возврата информации.

Чтобы рассчитать требования к хранилищу, нужно знать объем восстанавливаемой информации и допустимое время простоя. Также следует учитывать возможности остальных компонентов инфраструктуры: высокая скорость самой СХД не гарантирует столь же быстрого восстановления приложения.

Отказоустойчивость и доступность данных

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

Основные ситуации, которые следует рассмотреть:

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

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

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

Российские СХД для баз данных

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

YADRO TATLIN.UNIFIED

TATLIN.UNIFIED — универсальная СХД, которую можно использовать для баз данных, виртуализации и других корпоративных задач. Система позволяет объединить дисковые ресурсы нескольких серверов и управлять ими централизованно.

Оборудование поддерживает твердотельные SAS SSD и механические HDD. Для отдельных поколений и конфигураций также предусмотрены NVMe SSD. Возможность использовать разные накопители помогает подобрать состав дисковой подсистемы под особенности приложений.

Серверы подключаются к массиву через Fibre Channel, iSCSI и, в поддерживаемых версиях, NVMe/TCP. Система также предоставляет файловый доступ по NFS и SMB.

TATLIN.UNIFIED оснащается двумя контроллерами, которые одновременно обрабатывают запросы. Для защиты информации производитель разработал технологию T-RAID. Она распределяет данные между накопителями и позволяет сохранить их при определенных отказах дисков. Также доступны моментальные снимки и репликация между совместимыми системами.

Для каких задач подходит: размещение нескольких баз данных и виртуальных серверов, которым необходимо общее хранилище.

Например, предприятие использует 1С, внутреннюю учетную систему и несколько приложений на виртуальных машинах. TATLIN.UNIFIED позволяет разместить их дисковые ресурсы на одном массиве, выделяя каждому приложению необходимое пространство.

YADRO TATLIN.AFA

TATLIN.AFA — полностью твердотельная система для приложений, которые интенсивно обращаются к дискам. Ее основное отличие от TATLIN.UNIFIED заключается в архитектуре, построенной на технологии NVMe.

Модель использует платформу TATLIN.X. В корпусе высотой 2U размещаются два контроллера и до 24 накопителей NVMe SSD. Оба контроллера одновременно обслуживают запросы, а технология NVMe позволяет сократить задержки обмена информацией внутри системы.

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

Для каких задач подходит: 

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

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

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

Гравитон СХ424И24БМ-РЭ

Гравитон СХ424И24БМ-РЭ — российская система хранения данных с программным обеспечением RAIDIX 5.2. Производитель предусматривает ее применение для корпоративных СУБД, виртуализации и других задач.

В корпусе высотой 4U находятся 24 отсека для накопителей. Система поддерживает SAS SSD и HDD, а увеличить дисковое пространство можно с помощью дополнительных полок.

Одна из особенностей модели — возможность выбрать одноконтроллерное или двухконтроллерное исполнение. В двухконтроллерной конфигурации предусмотрено переключение доступа при неисправности одного из контроллеров. Поддержка NVMe-накопителей заявлена только для одноконтроллерного варианта.

Программное обеспечение RAIDIX отвечает за управление дисками, организацию защищенного хранения и предоставление ресурсов серверам. Для подключения используются Fibre Channel и iSCSI, а для файлового доступа предусмотрены NFS и SMB.

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

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

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

Aquarius AQstor LITE

AQstor LITE — система хранения данных Аквариус начального корпоративного уровня. Производитель предназначает ее для малого и среднего бизнеса, филиалов, удаленных офисов и вспомогательных задач в крупных организациях.

Модель оснащена двумя активными контроллерами и корпусом высотой 4U с 24 универсальными отсеками для накопителей. Поддерживаются твердотельные SAS SSD и механические NL-SAS HDD с возможностью горячей замены.

AQstor LITE предоставляет блочный доступ по Fibre Channel и iSCSI, а также файловый по NFS и SMB. Это позволяет подключать к системе серверы с разными способами организации хранения.

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

Для каких задач подходит: базы учетных приложений, виртуальные серверы и общие файловые ресурсы небольших и средних организаций.

Например, AQstor LITE можно рассмотреть для филиала, в котором несколько серверов обслуживают локальные учетные системы и внутренние приложения. Вместо отдельных дисковых массивов на каждом сервере организация получает общее хранилище с централизованным управлением.

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

СХД в наличии на складе в Москве

Показать варианты →

Российские СХД для хранения резервных копий

Для размещения резервных копий российские производители предлагают специализированные системы, универсальные дисковые массивы и объектные хранилища. Рассмотрим их на примере решений YADRO, Гравитон и Аквариус. Различия касаются способов записи, сокращения занимаемого пространства и возможностей расширения.

YADRO TATLIN.BACKUP

TATLIN.BACKUP — специализированная линейка YADRO, разработанная для хранения резервных копий серверов, баз данных и виртуальных машин.

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

Для ускорения передачи предусмотрена технология T-BOOST. Она выполняет часть обработки на исходном сервере и позволяет передавать по сети только уникальные блоки. Это может сократить продолжительность копирования и объем сетевого обмена. Для работы T-BOOST необходимы соответствующие программные компоненты и лицензия.

Линейка включает две модели:

• TATLIN.BACKUP.M — система с одним контроллером хранения. Поддерживает подключение до четырех дисковых модулей расширения и предназначена для типовых корпоративных задач.
• TATLIN.BACKUP.L — старшая модель с двумя контроллерами. Рассчитана на крупные инфраструктуры, которым требуется больше дискового пространства и резервирование контроллеров.

Еще одна особенность TATLIN.BACKUP — защита сохраненной информации с помощью моментальных снимков. Они фиксируют состояние данных на определенный момент времени. Например, режим Locked запрещает пользователям системы изменять и вручную удалять защищенный снимок. Возможность управления такими снимками ограничена, а необходимые функции безопасности могут зависеть от версии программного обеспечения и лицензии.

Производитель также предусматривает интеграцию с RuBackup, Кибер Бэкап и Veeam Backup & Replication. При использовании поддерживаемых сочетаний программного обеспечения можно организовать передачу и восстановление информации через соответствующие средства резервного копирования.

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

Например, предприятие регулярно сохраняет состояния большого количества виртуальных серверов. TATLIN.BACKUP позволяет сократить расход дискового пространства за счет встроенной дедупликации. Модель M можно рассматривать для типовой корпоративной инфраструктуры, а L — для более крупных систем с повышенными требованиями к доступности хранения.

Универсальные СХД Гравитон и Аквариус

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

Например, для этой задачи можно рассмотреть Гравитон СХ424И24БМ-РЭ и Aquarius AQstor LITE. Их технические характеристики мы разобрали в предыдущей главе. При использовании для резервного хранения важнее способ взаимодействия с программным обеспечением.

Программа создает копии и сохраняет их в выделенной области СХД. При необходимости она обращается к сохраненным файлам и выполняет восстановление. Оборудование предоставляет дисковое пространство и обеспечивает доступ к нему.

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

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

Например, организация сохраняет данные нескольких рабочих серверов на отдельной СХД Аквариус или Гравитон. Программа выполняет копирование по расписанию и управляет сохраненными версиями. Администратор получает единое место хранения, доступное для восстановления.

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

Объектное хранилище YADRO TATLIN.OBJECT

TATLIN.OBJECT — система YADRO для хранения больших объемов информации с объектным доступом. Ее можно использовать для размещения резервных копий, если соответствующую возможность поддерживает программа резервного копирования.

При объектном хранении информация записывается в виде отдельных объектов. Программа обращается к ним через специальный интерфейс. Один из распространенных способов такого взаимодействия — протокол S3, который поддерживает TATLIN.OBJECT.

Например, интеграция с RuBackup позволяет использовать объектное хранилище для размещения созданных резервных копий. При этом программа управляет заданиями копирования, а TATLIN.OBJECT отвечает за хранение и предоставление записанной информации.

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

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

Для каких задач подходит: централизованное хранение больших объемов резервных копий, в том числе из нескольких подразделений или территориально распределенных систем.

Например, компания собирает копии серверов из разных филиалов в одном хранилище. TATLIN.OBJECT позволяет организовать их прием через S3 и увеличивать емкость по мере роста объема информации.

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

Что проверить перед закупкой российской СХД

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

Совместимость с серверами и программным обеспечением

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

Основные способы подключения:

Fibre Channel, iSCSI и NVMe/TCP обеспечивают блочный доступ. Сервер получает выделенное дисковое пространство и работает с ним через операционную систему. Для Fibre Channel обычно используют специальные адаптеры и коммутаторы. iSCSI и NVMe/TCP работают через Ethernet, но требуют поддержки соответствующих протоколов.

NFS и SMB предоставляют файловый доступ. Например, сервер может обращаться к общей папке на СХД без выделения отдельного дискового тома.

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

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

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

Важно!

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

Работа с программами резервного копирования

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

Например, программа может поддерживать запись в сетевую папку по SMB или NFS, на выделенный дисковый том либо в объектное хранилище по S3. Однако доступность одного из способов подключения еще не означает, что все функции резервного копирования будут работать.

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

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

Комплектация и лицензии

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

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

В спецификации должны быть указаны:

• Контроллеры. Количество, исполнение и поддерживаемые режимы работы.
• Накопители. Тип, емкость, количество и возможность установки дополнительных дисков.
• Сетевые подключения. Типы и количество портов, необходимые адаптеры, кабели и модули.
• Программное обеспечение. Версия, состав лицензий и доступные функции.
• Дополнительные компоненты. Дисковые полки, блоки питания и другие элементы, предусмотренные проектом.

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

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

Наличие в реестре Минпромторга

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

Сведения о российской промышленной продукции размещаются в государственной информационной системе промышленности (ГИСП). В зависимости от категории оборудования и условий закупки могут применяться реестр российской промышленной продукции и единый реестр российской радиоэлектронной продукции.

При проверке нужно сопоставить наименование и исполнение СХД с действующей реестровой записью. Также следует уточнить ее номер и проверить, распространяется ли она на предлагаемую конфигурацию.

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

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

Испытания и техническая поддержка

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

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

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

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

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

• Техническая поддержка. Кто принимает обращения и помогает устранять неисправности.
• Замена компонентов. Как организовано обслуживание накопителей, контроллеров и других узлов.
• Обновление ПО. Какие обновления доступны и на каких условиях они предоставляются.
• Расширение системы. Какие компоненты можно добавить после установки и потребуется ли для этого дополнительная лицензия.

Важно!

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

Вопросы и ответы