В поиске надёжных и быстрых СХД? Используй решения компании StoreQuant

Системы хранения данных (СХД) являются ключевым элементом любой современной ИТ-системы, включая системы, ориентированные на поддержку бизнеса. Иностранные компании даже ввели термин, который описывает такие системы – Business Critical Systems или Mission Critical Systems.
Действительно, обработка и хранение данных является важной задачей, так как их потеря или кратковременные сбои в работе СХД могут привести к серьёзным последствиям для бизнеса в целом.

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

В данной статье мы расскажем об архитектуре СХД, её возможностях и преимуществах перед конкурентными решениями зарубежных вендоров.

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

Что покупают клиенты и есть ли выбор на рынке?

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

Основные требования, предъявляемые к современным СХД:

1. СХД должна работать 24х7 и поддерживать апгрейд без остановки сервиса.
2. В СХД должна быть реализована технология восстановления данных без участия пользователя в случае сбоя носителя информации.
3. Архитектура СХД не должна иметь единой точки отказа.
4. СХД должна адаптироваться к нагрузке со стороны приложений без изменения конфигурации самих приложений.
5. СХД должна содержать функции самодиагностики на уровне протокола доступа к данным.

Подавляющее количество сбоев СХД случается по причине ошибок в программном обеспечении или проявляется вследствие несовместимости на уровне протоколов доступа к данным.
Именно в соответствии с этими принципами мы создаём свои продукты и решаем задачи клиентов.

Что такое СХД и как её построить?

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

СХД представляет собой программно-аппаратный комплекс (в английской терминологии Appliance). Развитие СХД очень сильно обусловлено как раз программным обеспечением, которое на практике у многих вендоров называется «микрокод». В рамках программного обеспечения реализуются практически все важные элементы СХД, и это грамотный технический подход, так как он позволяет экономить на разработке аппаратного обеспечения СХД. Термин Software Defined Storage (SDS), в нашем понимании, является неверным, так как не может существовать чисто программной реализации для СХД, любая версия SDS так или иначе связана с аппаратурой и зависит от неё.

Мы изначально ввели ряд принципов, которых мы придерживаемся при разработке СХД:

• НЕ использовать Open Source-средства для управления данными;
• НЕ полагаться на архитектуру аппаратной платформы, за исключением особых критических функций СХД;
• НЕ программировать на низком уровне (Kernel), за исключением критических областей.

Многие пионеры, которые создают свои решения в области СХД, наивно полагают, что достаточно взять хорошо разрекламированный Open Source-пакет для управления данными в Интернет и можно решить любые задачи, предварительно взяв ещё недорогой сервер. Нетрудно догадаться, что Open Source-решения в области СХД создавались их авторами для совершенно других целей и что применять их для создания СХД нужно очень внимательно.

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

А кто обеспечит безопасность и целостность данных клиента?

Доверять Open Source-решениям управление данными в такой сложной системе, как СХД, очень рискованно.

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

Мы определили основные элементы СХД, о которых расскажем в данной статье.

Зачем строить СХД?

Мы будем освещать многие аспекты этого вопроса в дальнейшем, однако сформулируем основные причины сейчас:

1. Быть лидером в СХД – значит создавать СХД. Быть потребителем – покупать чужие решения.
2. СХД легко встраивается в любой ИТ-ландшафт, в отличие, например от российских СУБД, которые сложно адаптировать к существующим приложениям.
3. Большой ассортимент микрочипов, используемых в технологиях обработки и передачи данных, позволяет быстро проектировать новые и уникальные СХД-решения.
4. Серьёзная безопасность данных может быть обеспечена только в отечественном решении.

Мы постараемся изложить в будущих статьях интересные способы реализации алгоритмов обработки и хранения данных и просто инженерные решения.

А есть ли будущее у СХД?

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

Даже появление новых In-Memory-СУБД не отменяет СХД по вышеизложенной причине.
Именно поэтому мы первые реализовали на Российском рынке СХД на базе NVMe-носителей и представили своё решение в линейке StoreQuant Velocity Scale. Данный продукт является первым Российским СХД на базе NVMe-стандарта, уверенно конкурирует с иностранными аналогами и легко интегрируется в инфраструктуру SAN у любого клиента.

Далее мы расскажем про нашу архитектуру, продукты и решения.

Какую архитектуру мы используем в СХД StoreQuant Velocity Scale ?

Основной элемент архитектуры СХД StoreQuant – In-Memory-СУБД, гарантирующая сохранность данных на основе механизма обработки транзакций.

Любая операция, связанная с обработкой команды записи или чтения данных в СХД, должна соответствовать концепции ACID (Atomicity, Consistency, Isolation, Durability). Хранилище СУБД основано на хранении блочных данных, и его можно классифицировать как объектную базу данных. Задача СУБД также заключается в отказоустойчивой обработке данных в памяти нескольких контроллеров. Область памяти, которая используется СУБД для хранения данных в RAM мы называем Cache.

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

Рисунок 1. Структурная схема программного кода СХД

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

Рисунок 2. Структурная схема компонентов СУБД

Для чего необходим High Performance Scalable Link Switch ?

Особый компонент High Performance Scalable Link Switch, которому мы дали кодовое имя «URSUS», позволяет выполнять вызовы между User space и Kernel space без использования syscall (на схеме syscall free). URSUS позволяет абстрагироваться от особенностей реализации аппаратной платформы при работе с HBA-адаптерами, RAID-группами, внешними контроллерами СХД. Для реализации SDK URSUS мы использовали язык С++ и собственную библиотеку шаблонов на языке С++ для поддержки разнообразных примитивов и структур данных, способных решать задачи блочного хранения данных. В целях ускорения разработки мы создали SDK, который позволил нам создавать собственные модули для реализации различных функций обработки информации, например: кодирование информации, дедупликация, сжатие и т.д.

Как обеспечить обновление микрокода СХД в режиме 24х7 ?

URSUS позволяет выполнять обновление программных модулей СХД, выполняющихся в User space в режиме Online без остановки операций ввода-вывода. В ядре слоя URSUS мы не используем стандартные механизмы операционной системы и обращаемся напрямую к данным в Cache, таким образом мы используем zero-copy-механизм обработки данных. В отличие от уровня block layer в ОС Linux, где выполняется многократное копирование данных между различными структурами ядра ОС, мы не теряем время на обработку команд, и это позволяет снизить latency операций ввода-вывода на нашей СХД.

В чём мы лучше иностранных вендоров СХД ?

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

1. Партнёр полностью зависит от proprietary контроллеров на базе сложных и малодоступных процессорных технологий. Полученное решение в дальнейшем полностью зависит от жизненного цикла аппаратной платформы.
2. Полная зависимость от технической поддержки вендора во время разработки и в процессе эксплуатации, в частности и преимущественно в силу сложных FPGA схем, которые используются в системах иностранных вендоров.
3. Отсутствие гарантии защиты вашей интеллектуальной собственности, так как в процессе разработки требуется раскрывать исходный код вашего решения при проведении консультаций с технической поддержкой иностранного вендора.

Преимущество SDK URSUS заключается в следующих возможностях, которые мы гарантируем нашим партнёрам:

1. Архитектура SDK URSUS позволяет построить полноценную СХД с режимом работы 24х7.
2. Команда разработчиков не должна иметь квалификацию в создании СХД. Достаточно иметь навыки разработки программ под ОС Linux и языке C/C++. Не существует проблемы в поиске квалифицированных кадров.
3. Свобода в выборе аппаратной платформы для создания собственного СХД решения.
4. Возможность портирования кода SDK на любую архитектуру, в частности: ARM, Эльбрус
5. Высокая скорость разработки на базе SDK URSUS по сравнению с другими решениями и в частности такими open source решениями как LIO, SCST. В итоге партнёр сможет быстрее выйти на рынок с готовым решением.
6. Наличие исходного кода решения упрощает сертификацию решения под различные стандарты безопасности.

В своей ОС мы используем только стабильные версии ядра Linux из архива Vanilla Kernels.

Описание комплекта разработчика вы можете найти у нас на сайте по ссылке.

Как устроен RAID в СХД StoreQuant Velocity Scale ?

Основной базовый элемент хранения данных в СХД StoreQuant – RAID-группа.
Существуют различные конфигурации RAID-группы, которые отмечены в Таблице 1.
Таблица 1 – Конфигурации RAID-групп

Тип RAID	4 диска	16 дисков	64 дисков	128 дисков	256 дисков
RAID10	2D+2D	8D+8D	32D+32D	64D+64D	128D+128D
RAID50	3D+1P	12D+4P	48D+16P	96D+32P	192D+64P
RAID60	2D+2P	8D+8P	32D+32P	64D+64P	128D+128P

Parity-данные распределяются по схеме round-robin по дисковой группе таким образом, что выход из строя любого диска (например 3D+1P) не влияет на работу RAID и доступность данных.
В центре внимания всегда RAID группа из 4 дисков (базовая группа), используя которую можно собирать более сложные RAID-конфигурации на большем количестве дисков. Например: группа из 32 дисков в конфигурации 24D+8P состоит из восьми RAID-групп в конфигурации 3D+1P. Расчёт parity происходит в рамках базовой группы из 4 дисков, что позволяет значительно распределить нагрузку на диски и повысить скорость ввода-вывода.

Мы используем подход «Объединяй и властвуй»

Используя подход, который мы называем «Объединяй и властвуй», клиент может единовременно добавить минимум 4 диска в СХД и сконфигурировать RAID-группу, но может решить либо использовать её отдельно, либо добавить её в состав существующей RAID-группы. Приведённое в Таблице 1 разделение на 8, 16, 32 и т.д. дисков чисто условно, объединение может быть выполнено даже для минимальной RAID-группы из 4 дисков, но не более 256 дисков в рамках одной RAID-группы.

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

На данный момент мы поддерживаем протокол NVMе вплоть до версии 1.2 включительно.

Таблица 2 – Доступные модели дисков СХД StoreQuant на базе NVMe протокола

Модель диска	Форм-фактор	Объём данных, ТБ
StoreQuant DataFusion 500	2.5 inch / U.2	2
StoreQuant DataFusion 550	2.5 inch / U.2	3.6
StoreQuant DataFusion 600	2.5 inch / U.2	4
StoreQuant DataFusion 650	2.5 inch / U.2	8
StoreQuant DataFusion 700	2.5 inch / U.2	11

Зачем нужен BackEnd в СХД StoreQuant ?

Главная инженерная проблема любой СХД – создать производительный, отказоустойчивый канал для обмена данными внутри СХД. Любая операция ввода-вывода порождает множество операций внутри СХД, что приводит к необходимости использования шины для передачи данных с минимальной latency.

Если говорить об операциях ввода-вывода, то в любой СХД существует по сути одна атомарная операция – изменение данных, которая включает в себя prefetch (чтение) данных и последующую запись изменений на диск. В зависимости от объёма передаваемых данных и типа RAID, запись изменённых данных порождает множество внутренних операций ввода-вывода для каждого диска, входящего в состав RAID-группы.

Что такое Intel Non-Transparent Bridge ?

В своей архитектуре мы активно используем технологию Intel Non-Transparent Bridge (NTB), которая позволяет использовать встроенные возможности процессора для взаимодействия с внешними процессорными системами при помощи шины PCI Express.

Мы стремимся выпустить на рынок в России уникальные решения на базе Intel NTB, уже сейчас у нас есть готовы адаптеры для создания сетевого соединения между любыми двумя Intel-системами на расстоянии до 100 метров с помощью оптического многомодового кабеля.

Важно, что мы не используем протоколы InfiniBand или Ethernet для синхронизации данных между контроллерами СХД, что позволяет нам получить минимальную latency и достаточную для нашей задачи пропускную способность шины PCI express.

Для понимания того, какой результат позволяет получить Intel NTB, приведём количественные данные его тестов (ping pong для синхронизации данных в RAM): передача данных по линку x16 PCIe между двумя контроллерами СХД блоками по 8Кб, позволяет достичь пропускной способности 10 115 МБ/c (Мегабайт в секунду) при средней задержке в 0.81 мкс (микросекунда).

Почему следует использовать инфраструктуру Fibre Channel ?

Однако, так как у большинства клиентов используется технология Fibre Channel (FC) и имеется большое количество оборудования для инфраструктуры FC, то мы также поддерживаем протокол FC для организации шины BackEnd в СХД StoreQuant Velocity Scale. Следует отметить, что реализация протокола FC у большинства вендоров HBA-адаптеров позволяет значительно сократить наши затраты при разработке СХД, так как мы получаем уже готовый SDK, где основная работа уже происходит на уровне SCSI, а не FC. Наша стратегия заключается в поддержке минимум двух стандартов для шины BackEnd в СХД StoreQuant Velocity Scale.

Выбирая протокол для передачи данных для СХД, следует учитывать пропускную способность RAM, которая зависит от объёма памяти (количества DIMM, так как память многоканальная), типа памяти (частоты и скорости) и возможностей CPU.

Почему не стоит выбирать инфраструктуру Infiniband для организации BackEnd шины ?

Тестируя различные варианты платформ на базе Intel, мы получаем, что на практике сейчас средняя пропускная способность RAM DDR3 не более 20ГБ/с (Гигабайт в секунду) на стандартной двухсокетной машине с Intel Xeon E5 v3, поэтому верхняя граница скорости уже задана производителями платформ.

Наиболее широкое распространение в архитектуре Intel получила шина передачи данных PCI Express. Исходя из возможностей шины PCI express v3.0, мы получаем нижнюю границу пропускной способности данных, и тут возникает вопрос, какой протокол лучше использовать? Рассматривая маркетинговые ходы разных компаний на рынке, которые предлагают адаптеры на базе PCI express v3.0 со скоростью передачи от 100Gb/s и выше, мы понимаем, что таких скоростей достичь трудно, по крайней мере на стандартном оборудовании платформ на базе Intel ? по причинам приведённым выше.

Ситуация в любом случае будет улучшаться, так как сейчас готов стандарт PCI express v4.0 и там возможности значительно расширены.

Надстройка Infiniband над стандартным протоколом PCI express добавляет дополнительные накладные расходы — снижает пропускную способность канала передачи данных и увеличивает latency.

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

Какой протокол стоит выбирать для шины BackEnd СХД ?

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

В итоге мы получили следующие преимущества:

1. Мы сами диктуем стратегию развития своего протокола и не зависим от реализации и тонкостей изготовления адаптеров (встроенного микрокода) от стороннего иностранного производителя.
2. Мы сделали намного более дешёвую версию своего протокола, по сравнению с другими высокоскоростными стандартами на рынке. Поэтому мы более конкурентоспособны в плане предоставления более выгодного предложения нашим клиентам.
   

В следующих статьях мы расскажем про новые продукты StoreQuant на базе Intel NTB и возможные способы их применения.

Как мы масштабируем свои ресурсы в СХД StoreQuant ?

Масштабирование СХД при увеличении нагрузки, а также соблюдение политик Quality of Service (далее QoS) являются насущными задачами любого клиента. По нашим исследованиям, многие иностранные вендоры не имеют возможностей QoS, которые помогают однозначно без дополнительных финансовых вложений защитить критичные приложения в случае роста нагрузки СХД.

Мы вкладываем в термин QoS следующие возможности, которые отсутствуют у иностранных вендоров:

1. Возможность защиты Cache для конкретного приложения. Клиент сам настраивает объём Cache, который гарантированно доступен для приложения.
2. Возможность выделения ширины канала передачи данных на уровне RAID-группы под конкретное приложение для заданного тома.
3. Возможность балансировки внешнего доступа к данным на уровне портов ввода-вывода.
4. Доступ к данным на базе виртуальных WWN для портов ввода-вывода.

Базовый элемент архитектуры нашей СХД – контроллер, который имеет на своём борту два сокета под Intel Xeon, коммутатор для NVMe дисков, а также способен нести под свои «крылом» до 1500 МБ RAM, которую мы активно используем под Cache. Контроллер имеет высоту 2 Unit или 1 Unit и предназначен для установки в стандартный Rack. В составе контроллера имеется от 10 до 24 слотов для установки дисков NVMe.

Пример: Максимальная сырая ёмкость хранимых данных в рамках одного контроллера 2 Unit, используя диски ёмкостью 2ТБ, составляет 48 ТБ.

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

Один контроллер имеет до 4 внешних (FrontEnd) и 2 внутренних (BackEnd) портов ввода-вывода, в частности мы поддерживаем FC на скорости 16 Gb/s и 32 Gb/s.

Таблица 3 – Технические характеристики контроллера СХД StoreQuant

Тип контроллера СХД StoreQuant	Порты ввода-вывода (BE/ FE)	Объём данных (MIN/MAX)	Объём RAM (Cache)
DataFusion SmartNode v1.0	2 / 4	1.6ТБ / 110 ТБ	1500 МБ

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

Для защиты в случае ситуации Split-brain мы используем шину BackEnd, которая имеет несколько выделенных линий для передачи данных.

Особенностью нашей архитектуры является возможность на уровне системы управления СХД объединять контроллеры вместе, таким образом мы обеспечиваем защиту 1+1 на уровне контроллера и предоставляем возможность клиенту переводить трафик от серверов на выделенные порты ввода-вывода и разделять нагрузку между контроллерами. Таким образом контроллер всегда работает в паре (далее Base Module) с другим контроллером и представляет единый комплекс в составе СХД. На данный момент мы поддерживаем всего 512 Base Modules в составе своего СХД решения. Наши максимальные технические возможности с учётом работы всех 512 Base Modules представлены в Таблице 4.

Таблица 4 – Технические характеристики СХД StoreQuant в максимальной конфигурации

Количество портов ввода-вывода (FC) для Front End	Количество Cache (максимум)	Максимальный объём данных
4096	1536 ТБ	112 640 ТБ

С точки зрения апгрейда СХД, клиент может установить минимум один контроллер и включить его в структуру СХД. На Рис. 3 представлен пример СХД из трёх контроллеров, когда клиент устанавливает дополнительный контроллер C, что позволяет увеличить объём IOPS (операций ввода-вывода) всей СХД системы за счёт дополнительных портов ввода-вывода. В данном случае контроллер B образует две пары (Base Modules) с контроллером А и контроллером C, при этом все операции записи данных защищены синхронным копированием данных в Cache всех контроллеров. Используя контроллер C, клиент получает возможность предоставить альтернативный путь доступа к тому (X) для приложений, тем самым изолировать приложение использующее том (X) на уровне портов ввода-вывода от других приложений.

Рисунок 3. Конфигурация Base Module СХД StoreQuant

Необходимо отметить, что управление томами и RAID-группами происходит в режиме Online без остановки сервиса СХД, т.е. с помощью механизма Snapshots можно перенести том с одной RAID-группу на другую RAID-группу в рамках разных контроллеров. Мы поддерживаем два вида Snapshots – СOW (Copy-on-write) и Full snapshots, а также возможность синхронизации Snapshots во времени для репликации измененных данных и сокращения времени создания Snapshot.
Мы специально не используем системы типа JBOD в своей архитектуре, так как по сути наш контроллер выполняет функции JBOD, т.е. хранит данные и предоставляет к ним доступ, а также функции контроллера, т.е. обеспечивает защиту данных и управляет RAID-группами.

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

Что такое Active-Active конфигурация в СХД StoreQuant ?

Большинство СХД систем на Российском рынке предлагают возможность доступа к данным (томам) через активные порты ввода-вывода в рамках минимум двух различных физических контроллеров. Однако на Российском рынке существуют такие СХД системы, которые понимают термин Active-Active иначе и намеренно вводят неверное понимание в своих маркетинговых материалах. Попробуем объяснить как выглядит Active-Active конфигурация, лучше всего будет обратиться к наглядному примеру ниже на Рис. 4.

“Cache Sync” позволяет синхронизировать все операции записи данных между контроллерами, используя шину BackEnd.

Рисунок 4. Конфигурация Active – Active СХД StoreQuant

Нетрудно увидеть, что конфигурация на Рис. 5 приведёт к отказу в доступе к данным при выходе из строя контроллера СХД, что безусловно является недопустимым событием. Мы не используем данную конфигурацию в своём продукте.

Рисунок 5. Конфигурация без защиты доступа к данным

Как мы балансируем доступ к данным на уровне LUN в СХД StoreQuant ?

Важным моментом при выборе СХД является возможность доступа к данным на уровне LUN, т.е. диска в терминах SCSI. В случае Active-Active конфигурации мы реализуем подход, который разделяет адресное пространство тома таким образом, что каждый контроллер в паре может обслуживать операции записи данных отдельно. Большинство СХД всегда реализует доступ к данным по схеме, где только один контроллер может быть Master, а другой Slave, при этом Slave выполняет роль «прокси» контроллера, т.е. он передаёт запросы Master контролеру и возвращает результат, но не выполняет команды самостоятельно.

Наш подход в архитектуре СХД StoreQuant, позволяет добиться большей скорости при обработке операций ввода-вывода, а также оптимизировать использование ресурсов каждого контроллера. Адресное пространство каждого тома разделяется в соотношении 50/50 между парой контроллеров (Base Module), что позволяет активно использовать ресурсы каждого контроллера в СХД.

В итоге, выбирая архитектуру СХД StoreQuant наши клиенты и партнёры получают:

1. Масштабируемое и надёжное СХД с режимом работы 24х7 и гарантированной технической поддержкой с услугой 8 часов call-to-repair.
2. Возможность установки нашего решения на аппаратную платформу клиента и создание уникального решения для нужд нашего клиента.
3. Гибкая лицензионная политика СХД StoreQuant значительно сокращает расходы и экономит бюджет.

В следующих статьях мы расскажем про технические решения актуальных задач у наших клиентов.