Ряд предыдущих статей мы посвятили подробным обзорам различных продуктов Qsan. В основном это были их блочные СХД серий XCubeSAN и All Flash массивы XCubeFAS. Выбор объектов для обзоров был не случаен. Ведь именно эти серии составляют львиную долю продаж на только в РФ (в том числе благодаря нам), но и во всем мире. Надежность и высокая производительность, вкупе с простым и понятным управлением, сделали продукты весьма популярными. Однако, в настоящее время сугубо блочные СХД уже не выглядят локомотивом прогресса. Поэтому настало время поговорить о Unified системах Qsan – серии XCubeNXT.

Существуют различные технологии по уплотнению ресурсов физических серверов с целью их более эффективного использования. Наиболее известный вариант – это виртуализация. Именно в данной сфере системы хранения данных (СХД) являются одним из ключевых элементов, поскольку позволяют достаточно легко реализовать кластеры высокой доступности (HA cluster). Однако, помимо виртуализации доступны иные методы повышения эффективности, одним из которых является применение контейнеров.

Мы продолжаем публикацию статей в стиле how-to касательно использования систем хранения данных (СХД) Qsan в различных типовых задачах. На сей раз рассмотрим первичную настройку серверов на базе операционных систем (ОС) семейства Linux при подключении блочных томов со стороны СХД.

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

Наш мир устроен так, что ничто не вечно под Луной. Другими словами, абсолютно все может прийти в негодность. Ну или, применительно к IT отрасли, может дать сбой. IT индустрия буквально пропитана идеей резервирования всего и вся ради обеспечения непрерывности работы и доступности сервисов. Начинаем с дублирования компонентов в рамках отдельной «железки», далее выполняем дублирование самих серверов, строим кластеры, резервируем каналы связи, осуществляем территориальное распределение и так далее. Все это напоминает спираль, где каждый новый виток означает очередное дублирование уже имеющейся IT инфраструктуры на более высоком уровне. Вопрос лишь в том, когда происходит остановка. Ведь давно уже не секрет, что очередная девятка после запятой в числовом значении доступности сервиса означает увеличение стоимости решения на порядок (то есть в 10 раз!).

Количество атак Ransomware, также известных как вирусы-шифровальщики, постоянно растет. Что, впрочем, нисколько не удивляет: ведь это весьма прибыльный теневой бизнес. Абсолютное большинство публичных компаний, которые были успешно атакованы, предпочитают не выносить сор из избы, чтобы не афишировать свои промахи в сфере кибербезопасности, все же заплатили выкуп вымогателям. Те же, кто отказался платить мзду, навсегда потеряли часть своих данных.

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

Ни для кого не секрет, что большинство вендоров СХД привязывают своих пользователей к накопителям собственной торговой марки. Так что типичный подбор, например, SSD подразумевает определение парт-номера накопителя в соответствии с характером нагрузки (read, mixed, write) и его емкостью. В целом, данный подход призван облегчить жизнь IT отделу, но при этом создать повышенную нагрузку на бюджет компании. А бюджеты, как известно, не резиновые. Поэтому всегда существовали и будут существовать вендоры, производящие решения из области хранения данных, которые позволяют использовать накопители сторонних производителей. В этом случае у пользователей имеется гораздо больше возможностей по выбору тех или иных накопителей, поскольку листы совместимости СХД содержат в себе большое количество позиций.

Еще, казалось бы, недавно для всех нас деревья были выше, трава зеленее, а в качестве накопителей в серверах и СХД применялись только жесткие диски. Однако сейчас уже привычные SATA/SAS SSD считаются вполне заурядными компонентами систем хранения данных. Более того, все чаще начинают применяться NVMe SSD. Они используются не только для задач кэширования, но и для хранения оперативных данных. Поэтому на рынке растет число предлагаемых All Flash NVMe решений.

Окружающий мир определенно не такой, каким он был десяток лет назад. В то время никто бы не поверил, что за нами будет пристально следить 24 часа в сутки огромное количество видеокамер. Если раньше видеонаблюдение было развернуто лишь в наиболее уязвимых, с точки зрения безопасности, местах, то сейчас редко можно встретить даже мелкий магазинчик без собственных видеокамер. В крупных мегаполисах применяется масштабное наблюдение за улицами, дворами домов и прочими общественными местами. Можно по-разному относиться к постоянному наблюдению за людьми и объектами (кто-то видит в этом безопасность, а кто-то – признаки тотального контроля), но решать технические вопросы в данной сфере все равно необходимо.

Мы продолжаем цикл публикаций из серии How To для пользователей СХД Qsan. В данной статье пойдет речь о подключении СХД к серверам на базе Windows Server, в том числе при использовании функционала виртуализации Hyper-V.

Эксплуатация технически сложного оборудования, типа систем хранения данных, подразумевает наличие у администратора определенных навыков. Однако высокие технологии шагают в массы. И, соответственно, растет число пользователей, впервые столкнувшиеся с ними. Уверены, что статьи в стиле How To являются отличным способом пополнить багаж знаний как для новичков, так и узнать нюансы и особенности для опытных пользователей.

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

Информационным поводом для написания данной статьи стала официальная поддержка со стороны Qsan подключения к СХД полок расширения сторонних производителей. Этот факт заметно выделяет Qsan среди прочих вендоров и даже в некоторой степени ломает привычное положение на рынке СХД. Однако просто написать о связке СХД Qsan + «чужой» JBOD нам показалось не так интересно, нежели затронуть отчасти холиварную тему использования компонентов сторонних производителей.

Современный мир уже сложно представить без обилия медиа контента, представленного, в том числе, в виде аудио и видео данных. Казалось бы, еще совсем недавно пределом мечтаний была коллекция MP3 файлов. А сегодня видеофайлы с разрешением 4K уже воспринимаются как нечто обыденное. Весь этот медиа контент нужно создать, где-то разместить и затем предоставить к нему доступ. Современные системы хранения данных (и Qsan в том числе) как нельзя лучше подходят в качестве одного из основных инструментов по работе с контентом.

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

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

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

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

Технологии повышения производительности, основанные на использовании SSD и широко применяемые в СХД, уже давно изобретены. Прежде всего – это применение SSD в качестве пространства хранения, что на 100% эффективно, но дорого. Поэтому в ход идут технологии тиринга и кэширования, где SSD используются только для наиболее востребованных («горячих») данных. Тиринг хорош для сценариев долговременного (дни-недели) использования «горячих» данных. А кэширование, наоборот, для краткосрочного (минуты-часы) использования. Оба этих варианта реализованы в СХД QSAN XCubeSAN. В данной статье мы рассмотрим реализацию второго алгоритма – SSD кэширования.

На текущий момент предложения на рынке корпоративных NAS разделились на два полярных лагеря. В одном лагере находятся дорогие и функциональные системы типа Netapp FAS или EMC Unity. В другом – выходящие за рамки сегмента домашних устройств решения вроде QNAP или Synology, которые привлекают своих потенциальных пользователей прежде всего умеренной стоимостью. И вот в этот огромный неохваченный сегмент между указанными лагерями мы предлагаем поместить героев нашего обзора – NAS серверы QSAN серии XCubeNAS.