SAN *

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

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

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

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

Привет, Хабр! Меня зовут Сергей Качкин. Вместе с командой я занимаюсь тестированием производительности систем хранения данных: много тестов делаем сами, видим результаты наших коллег и заказчиков, так у нас накопилось некоторое количество опыта, которым хочется поделиться. 

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

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

Речь пойдёт о системе записи с IP-камер Surveillance Station от Synology. Я сам уже много лет использую Synology, причём впервые познакомился с ней ещё до покупки оригинального железного сервера, установив через Xpenology фирменную операционную систему на обычный компьютер.

Xpenology является загрузчиком операционной системы от Synology, которая называется DSM (DiskStation Manager) и используется на  фирменных NAS Synology. DSM работает на пользовательской версии Linux, разработанной Synology.

Веб-приложение Surveillance Station - это система NVR (сетевой видеозаписи) для обеспечения безопасности с помощью мониторинга IP-камер. Это приложение кажется довольно удобной, хотя и проприетарной системой видеонаблюдения, которая работает прямо из коробки. По умолчанию возможно бесплатное подключение только двух камер.

Однако бразилец Фабио Белавенуто в июле 2022 выложил на гитхабе проект загрузчика Automated RedPill Loader (ARPL), который позволяет практически без использования командной строки создать загрузочную флешку и протестировать запуск Synology DSM 7.1 и Surveillance Station 9.0.1-7673 на 8 камер без какой либо дополнительной оплаты на обычном компьютере при эмуляции сетевого хранилища DVA1622.

• ucs-6100-k9-kickstart.5.2.3.N2.2.23e.bin;
• ucs-6100-k9-system.5.2.3.N2.2.23e.bin;
• ucs-manager-k9.2.2.3e.bin.

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

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

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

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

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

Электронное хранилище

LINSTOR​​​ - это инструмент для автоматизированного управления кластерами, который позволяет упростить управление DRBD​​ и предлагает широкий спектр функций, включая резервирование и моментальные снимки.

LINSTOR​​ - это программное обеспечение с открытым исходным кодом, предназначенное для управления блочными устройствами хранения в больших кластерах Linux серверов. Оно упрощает развертывание хранилища высокой доступности с помощью распределенного реплицированного блочного устройства версии 9 (DRBD​ 9), динамически резервирует хранилище и упрощает управление посредством интеграции с Kubernetes, Docker, OpenStack, OpenNebula, OpenShift и т.д. Кроме того, LINSTOR​​ может обеспечивать высокую доступность с помощью DRBD​​. В этой статье я рассмотрю настройку и работу этого инструмента.

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

Что трудного в том, чтобы автоматизировать такие рутинные задачи с помощью нескольких скриптов? Но дело в том, что при автоматизации необходимо уделять внимание мельчайшим деталям, поскольку этот процесс содержит много потенциальных ловушек для администратора. Какие-то мелкие моменты, которые могут быть не заметны при ручном администрировании, легко могут привести к проблемам в автоматизации – например, когда файлы устройств еще не существуют в файловой системе /dev, хотя соответствующая команда для создания тома уже сообщила о завершении, или если вы хотите удалить не смонтированные тома, которые используются подсистемой udev. Если дополнительно требуется централизованное управление целым кластером, а не только одной системой, становится ясно, что несколько готовых скриптов не справляются с этой задачей.

Мы решили выяснить насколько эффективны новые решения VMware vSAN 7 и можно ли с их помощью снизить издержки на содержание СХД, в том числе за счет увеличения количества гиперконвергентных структур в одном кластере. Я собрал стенд с четырьмя серверами различных конфигураций для тестирования vSAN 7.0. Результаты получились весьма обнадеживающими, подробности — под катом. 

У меня стоят нотификации ebay на некоторое количество старого серверного железа, которое уже никому не нужно, но в обычной ситуации продолжает стоить неприлично. Для домашней лабы и желания поиграться - цена неоправданна совсем, но периодически всплывают очень интересные варианты. В этих-же email-ах есть "похожее". И в какой-то момент я увидел в этом "похожем" предложение на SAS switch (LSISAS6160). У продавца было 3 штуки, каждая по $80. Главной потенциальной проблемой было то, что они были без БП, а он там внешний (12А 75W), думаю - разобраться и найти аналог не проблема. Понимая, что один - это мало, так как будут эксперименты, и зная нашу таможню - я предложил у него купить сразу все три оставшихся, но по $65. Он согласился. Ехало это всё примерно месяц.

tl;dr Как сжечь старое серверное железо без фирменного блока питания

TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.

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

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