Главная » Хабрахабр » Что умеет СХД — или старые песни о главном

Что умеет СХД — или старые песни о главном

Пару дней назад позвонили мне коллеги с вопросом — старая дисковая полка совсем умирает (у них старый еще IBM), чего делать? Дисков нет, поддержки нет, денег нет зовут Олег.

Что покупать, куда бежать, как дальше жить?

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

Новых авторов тоже что-то нет, про, скажем, 3par с 2015 года почти ни слова (зато, внезапно, нашелся материал по Huawei Oceanstor — так что будет много ссылок про него).

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

Кратко и с ошибками, в присущем автору стиле «валим в кучу». TL/DR Что там творится в СХД «сейчас».

image

Итак, что умеют современные СХД из разряда «дорого конечно, но выбора особо нет».

Младшие системы хранения
1. 1. Системы уровня «сделай сам».
1. 1. То же самое, но с завода и с обновлениями от производителя.
1. 2. Младшие всамделишные СХД. 3. Гиперконвергентные системы хранения.
3. Уже с перламутровыми пуговицами.
2. Современные СХД среднего ценового сегмента.
5. Системы на базе Ceph, Gluster и так далее.
4. Куда это все развивается.
7. Современные СХД старшего ценового сегмента не будут рассмотрены, хотя там тоже интересно.
6. Ссылкота и что еще поискать и почитать, в том числе на русском. Немного выводов.
8.

Младшие системы хранения 1.

1. 1. Системы уровня «сделай сам».

Windows умеет собирать програмный Raid 5 с времен Server 2003, и отдавать его по iSCSI тоже где-то с Server 2003. Ничего сложного в этом нет — взяли любой контроллер SAS дисков, или даже без него, взяли любой корпус «побольше», набили туда дисков, собрали из них Raid 1-10-5-6, и отдали по 10G iSCSI. Linux тоже умеет и raid, и iSCSI target, процесс настройки описан, я делал.

Проблемы у такого самосбора есть во всем, начиная от скорости работы самого массива, заканчивая мониторингом (SNMP нет, контроллер ничего не умеет, а агент Zabbix ставить надо), скоростью перестроения и различными аппаратно-программными фокусами в работе.

Комментарий от коллег:

Внизу будет ZFS, ну так каждый злобный буратино сам выбирает чем себя развлечь. Ну кстати зря, FreeNAS даст всё из коробки.

Raid-10 конечно, Storage Spaces, JBOD полка SS и головы на DL120g8. И скорость вполне цивильная, десяток 900gb 10k вполне тянул средненький бузинес (Экс ~ 100 рыл с жирными ящиками, Шарик, терминалы и прочая мишура).

Вообще, самое на мой взгляд больное место современных простых массивов — это скорость перестроения Raid 5-6 на емких и дешевых дисках 7200 SATA / NL-SAS.

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

Второй и ТРЕТИЙ диск у меня при таких ребилдах вылетали, иногда приходилось данные брать из бекапа.

Например, у нас массив из 24 дисков, без диска горячей замены (в шкафу лежит). Решения вида «а давайте соберем не 6, а 60» приводит к легкой форме амфибийной асфикции (удушения жабой). Это конечно не -12 от Raid10, но уже стремительно к нему приближается. Разбиваем его на 3 блока по 6+2 диска, собираем R60 и получаем свободной емкости "-2 с каждого блока, всего -6".

Да, и не все контроллеры поддерживают Raid60, да и на 6-8 Тб дисках все равно будет грустно.

1a. 1. Отдельно надо отметить решение «как бы непойми что» — это например вот такое.

или какой ARM ?, и намеки на полные потери данных в комментариях. Ни слова о том, что за ноды, что за контроллеры, что с снапшотами и бекапами, что там за «ну у нас не x86 в базе» — а что, малинка?

2. 1. То же самое, но с завода и с обновлениями от производителя.

Не совсем уж самые младшие «для дома — SOHO», с ZFS и неонкой, а что-то похожее на СХД. Это младшие QNap, Synology, кто там еще.

0), хотите NFS, можно FTP. В таких СХД уже два блока питания, два контроллера SAS подороже, две сетевые карты 10G, или даже может быть FC 8/16, и все, что сверху определено програмно — хотите iSCSI, хотите SMB (а если вы смелый, то даже и SMB 1. На контроллере даже кеш с батарейкой имеется! Хотите — даже можно тонкие диски сделать. Конечно, это не такая большая батарейка, чтобы джва часа крутить диски, но есть.

Скорость и ребилд. Система хорошая, рабочая — но проблемы те же, что и у самосбора. И да, при обновлении будет перерыв в работе минут на 30 (если ОС) или на пару часов (если еще и FW контроллеров), и часто откатиться нельзя.

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

3. 1. Уже с перламутровыми пуговицами. Младшие всамделишные СХД.

То, что в книжка с картинками называется «entry-level»
Из известных это линейка HPE MSA — 2052, 2050, 2042, 2040, 1050, 1040, и старый-старый P2000 G3, хотя его уже давно не продают.

Такое есть и у Dell конечно (Dell Storage SCv2000), да и Lenovo, старые Huawei.

К примеру, сейчас старое (4-е) поколение линейки HPE MSA заканчивает жизненный цикл, как скромно пишут на сайте HPE — покупайте 1040 -> 1050, 2040 -> 2050, 2042 -> 2052.

Появляются снапшоты на уровне СХД, тиринг (tiering), и удаленная репликация. На этом уровне появляются такие функции, как апгрейд прошивки контроллера без перерыва сервиса, возможность замены контроллера на следующее поколение (только контроллера), само собой «горячая замена всего» — дисков, контроллеров, блоков питания. Почитать не по русски можно скажем тут — HPE MSA 2050 SAN Storage — Overview, или тут HPE MSA 1050/2050/2052 Best Practices , или тут в переводе

Проблемы с перестроением Raid здесь все те же, и добавляются новые — с тем же тирингом.

Если не знают, то Что такое тиринг, я надеюсь, все знают.

Тиринг:

После чего у нас СХД смотрит (пару суток), к каким данным чаще обращались (горячие данные), и оставляет их на SSD, а более «холодные» отправляет на уровень ниже. это объединение в одну группу хранения 2-3 типов разных дисков и типов Raid, например — собираем в одну группу SSD в Raid 10, и SATA 7200 в Raid 6 / 60. Вот только перестроение идет раз в сутки, а иногда надо «сейчас». В результате горячие данные лежат на SSD, совсем холодные на дешевых SATA 7200. Массив не оперирует отдельными файлами виртуальных машин, поэтому ускорить «одну машину туда прямо сейчас» не выйдет, разве что имея в запасе гарантированно быстрый отдельный LUN, и перебросив машину (из среды виртуализации) на него или вообще на локальные хранилища хоста виртуализации.

Простой пример — СХД куплено «задорого», а потом к ней запускают горе-специалистов из(от) того же Гилева, и они начинают в среде виртуализации гонять CrystalDiskMark, чтобы попробовать получить на выходе скорость чтения на уровне самого медленного уровня хранения. Новые, свежие проблемы и боли начинаются примерно здесь, причем проблемы не с СХД. Зачем они так делают — не понятно совсем.

Как говорится, чего только люди не сделают, вместо покупки нового сервера 1U с быстрыми процессорами и многопамяти «только под 1с» — например с
Intel Xeon Gold 5122(3. Впрочем, кто допускает в свою инфраструктуру таких горе-спецов, оплачивает весь этот труд своими деньгами, это их право. 5MB/105W) Processor
или Intel Xeon Platinum 8156(3. 6GHz/4-core/16. 5MB/105W) Processor
Кстати, надо будет и себе такое чудо под 1с попросить прикупить — денег нет, но запрос цен на Dell/Lenovo/Huawei/HPE пожалуй сделаю. 6GHz/4-core/16.

Гиперконвергентные системы хранения. 2.

Это совсем не младший сегмент, особенно Nutanix, однако, учитывая повсеместную горячую любовь к импортозамещению «по трофейному», и наличие Nutanix CE (у некоторых даже и в продуктиве), то придется разместить тут.

С последним все очень весело, система называется «ни дня без патчей», «мы опять страдаем», или, как c последним обновлением 6. Проще говоря, гиперконвергентность — это сервер набивается дисками и SSD, и рабочие данные лежат локально на тех же серверах, где и работают виртуальные машины (а копия — где-то еще).
Из широко известных систем это Nutanix (целиком, как програмно-аппаратный комплекс, хотя есть и CE «на посмотреть»), MS Storage space direct (S2D), VMWare VSAN. 7u1 — «мы сломали вам бекап, МВУ ХО ХО».

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

Ряд производителей (кроме самого Nutanix) уже продает такие системы — к примеру Dell XC Series.

У всех. В целом у этих систем мне кажется что все неплохо. Даже дедупликация с компрессией имеется. И MS активно продается (причем даже в формате Azure stack — уже две штуки в РФ), и Nutanix растет и по продажам, и по капитализации, и выигрыш в скорости работы в некоторых сценариях у Nutanix порядочный, реально «в разы», вплоть до роста скорости работы некоторых сервисов по обсчету фотографий с 5 часов до часа (если не быстрее).

Судя по финансовым показателям, у VMWare в целом пока тоже все неплохо.

Системы на базе Ceph, Gluster и так далее. 3.

Или данные не жалко. Можно что-то подобное собрать и на open source компонентах, особенно если вы смелый, и (или) у вас есть штат разработчиков, как в Кроке. Или может просто фарту масти. Конечно, такого как в Cloud Mouse больше не будет, что вы что вы.

примеры раз
примеры два
примеры три

Проблемы с внедрением таких решений есть:

  • технические: а как это все бекапить? И сколько будет перестраиваться при отказе одного диска или одной машины? Как правильно настраивать и кто будет поддерживать? А сколько займет восстановление?
  • административные: А если ваш администратор попадет под трамвай или просто уволится, то кто и почем возьмется за поддержку? Сколько это будет стоить? А если вы вдруг потеряете вашу роскошную команду разработчиков в полном составе? Конечно, это не связка ключей, но бывает что люди уходят сразу командами.

Комментарий от коллег:

А то есть прохладная история, как упавшая Симметра уронила ЦОД в одном ФГУПе (с). А что будет при блэкауте? Упавшая в прямом смысле, фальшпол провалился.

Как и весёлые сварщики в другом ФГУПе, показавшие капиталистическому инвертору суровое русско-таджикское «Ага!».

Так что, как это всё будет заводиться и чиниться, при 100500k IOPS записи в секунду при падении — вопрос.

Медведя можно научить играть на балалайке, а вот глюстер чинить…
А если вы не в Дефолт Сити, а в каких-нить хибинях, среди медведей и комаров?

В среднего уровня СХД, к слову, стоят и батарейки на кеш (или суперконденсаторы), или целиком свои батарейные модули, да и сам кеш тоже частично в RAM, а частично в SSD и при провале питания всего ЦОД — аккуратно переложит все что не успел — в журналы транзакций и в свой резервированный кеш.

НО БЕКАП ДЕЛАТЬ ВСЕ РАВНО НАДО.

Современные СХД среднего ценового сегмента. 4.

Как я уже писал, поиском по хабру быстренько нашлось три статьи про Huawei OceanStor

Huawei OceanStor Family, три строки вот тут
и тестирование All-flash OceanStor Dorado V3 . Импортозамещение Часть 2.

Есть парочка обзоров 2012-2015 года по 3par
пример
Обзоров по Dell, IBM Storwize я как-то не искал, может и зря.

В большом интернете материалов на русском чуть больше, например тот же Oceanstor рассмотрен тут(кстати, в целом полезный бложек, набит ссылкотой по Huawei).

1 В первую очередь, это новый подход к разбиению дисков. Итак, что нам предлагает современный массив уровня HPE 3par / Huawei / IBM-Lenovo.
4. 0 и у Lenovo-IBM это Storwize Distributed RAID (DRAID). Это 3Par RAID, Huawei Raid 2. Вообще есть видео, хотя и на английском, но все понятно. Зачатки этого по слухам были еще в HP Enterprise Virtual Array (EVA), в 3Par пришло к логичному и более-менее понятному состоянию.
Как это работает.

HPE 3PAR StoreServ Architecture Overview ChalkTalk

0 Technology
Или (подольше, подробнее и на русском) — Вебинар E=DC2 №2: Технология RAID и её применение — про Raid 2. Huawei RAID 2. 0 с 1:18.

Как это работает, если описывать словами, а не картинками.

Просто группа дисков, разных — например, SSD и SATA.
Каждый отдельный диск разбивается на логические блоки по 64/256/1Гб (у всех по разному), называемые тоже по разному. Сначала мы выделяем дисковый домен. У HPE это chunklets, у Huawei chunk, у IBM — extent (но это не точно).

А из не более N, массив R5 из 50+1 вы несеберете, и размазанных по разным дискам!), chunklets\chunk должны быть одинакового типа (например SSD), емкость дисков и их количество к слову тоже регламентировано, типа «диски одинаковые, добавлять парами — 2,4) собираем массив „какой нам нужен“. Потом уже из этих chunklets\chunk (не из всех сразу! Точнее не „собираем“, а выбираем „как нам тут собрать“. Например на SSD нам нужна скорость — собираем R10, а на SATA важен объем — собираем Raid 5. Полученные chunklets\chunk group собираются в группы, группы нарезаются мелкими секторами (под тиринг), жучка за внучку, и в итоге получаем тонкий или толстый логический диск (уже LUN или файловая система под SMB), нужного размера плюс зарезервированное пространство „под ребилд“. Никаких 100500 ручных операций тут нет. Детально можно посмотреть например тут.

Какие плюсы от такого подхода к разбиению.

Плюсы достаточно простые.

В первую очередь, это гораздо более быстрое перестроение при сбое одного диска.

Бекапы делать все равно надо! ВНИМАНИЕ! Raid — не бекап, и не защитит от некорректного изменения данных никак.

Тут конечно надо бы рассмотреть такой функционал, как запись полными страйпами, но этим сейчас сложно кого-то удивить.
В результате перестроение идет в разы быстрее. Если при сбое диска в Raid5/6 нам надо было прочитать все данные, посчитать математику и записать все данные на один диск, то узким местом становился сам результирующий диск.
Здесь же запись будет идти на все диски сразу.

Как это работает с точки зрения математики и Raid.

Raid никуда не делся, просто стал немножко более виртуальным. Спешу всех успокоить, магии тут нет.

и +запасные в каждом. Пусть у нас 2 массива на 20 дисков. 19+1.
Второй массив собран из дисков по 1Тб как Raid 50. 1,2 — не важно.
Диски разные, но суммарный сырой объем массива одинаков.
Первый массив собран из дисков по 2Тб как Raid 5. Итого (4+1)*4 4 группы Raid 5 по 5 дисков собраны в raid-группу.

В разных дисковых группах для второго массива. Пусть у нас вылетает по суммарному объему в 2 Тб в каждом случае.

Скорость записи на один диск будет — пусть 10 IOPS (у нас штрафы на raid не отменены и есть прочая нагрузка). В первом случае нам надо прочитать данные с 19 оставшихся дисков, посчитать „что было потеряно“ и записать на 1 диск.

Во втором случае нам надо прочитать данные только с 8 дисков, и записать данные уже на два диска, по 10 IOPS на каждый диск, итого 20.

Астрологи объявили неделю перестроения, скорость перестроения удваивается.

К тому же мы знаем, какие микромассивы использовались, а какие нет, и можем выкинуть из перестроения пустое пространство. Теперь выясняем, что у нас таких „микромассивов 5+1“, по сотне мегабайт (максимум гигабайт) каждый, совсем не 4, а весь диск. Кроме того, резервное место размазано по всем оставшимся дискам, и запись будет идти на все диски сразу, со скоростью 10*N, где N — число дисков.

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

Если в массиве на 20 дисков и Raid 6 вы теряли 2 диска, 2/20, 10% то здесь место будет использовано как под резервирование на перестроение, так и под те же Raid 6, если вы возьмете 6+2 — то потеряете 2/8, 25%.
С другой стороны, есть и плюсы — одной из причин использования Raid 6 есть уже значимый риск возникновения коллизии на массивах R5 при использовании дисков „от 1 Тб примерно“. За все надо платить, и такое разбиение не исключение. Другой причиной является „долгий ребилд с риском утраты еще одного диска, что фатально для R5“. В цифрах риск может и небольшой, но не хочется терять данные. Здесь же дисковые группы небольшие, риски коллизии значительно ниже, перестроение быстрое — и в некоторых случаях можно сделать R5.

Теперь для тех, у кого возникнет вопрос „а как это живет в тот самый момент вылета, до перестроения“ — отвечу цитатой:

The following logical disk types are created by the system: The system sets aside logical disks for logging, for preserved data, and for system administration.
These logical disks are multi-level logical disks with three way mirrors for enhanced redundancy
and performance.

Logging logical disks are created by the system
during the initial installation and setup of the system. • logging logical disks are RAID 10 logical disks that are used to temporarily hold data during
disk failures and disk replacement procedures. Each controller node in the system has
a 60 GB logging LD.

How spare chunklets work:

Logging disk space is allocated when the
system is set up. • When a connection is lost to a physical disk or a physical disk fails, all future writes to the
disk are automatically written to a logging logical disk until the physical disk comes back
online or until the time limit for logging is reached. This does not apply to RAID 0 chunklets which have no fault-tolerance.

2. • If the time limit for logging is reached, or if the logging logical disk becomes full, the relocation
of chunklets on the physical disk to free chunklets designated as spares starts automatically.
Free chunklets are any chunklets that are not already allocated for use by logical disks.
HP 3PAR StoreServ 7200 2-node Administrator's Manual: Viewing Spare Chunklets
3PAR InForm OS 2. 4 Concepts Guide

2 Кроме быстрого перестроения, такое разбиение добавляет возможности делать всякое удобное в формате „тонких дисков“. 4. Тут, за счет кешей и предварительного выделения места „про запас“, проблем чуть меньше. В принципе, это умеет делать и Microsoft, и Vmware, но оба с своими интересными особенностями в плане скорости.

3 Дедупликация и сжатие. 4.

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

Если у вас данные „похожие, а то и такие же“, например какой-то LUN выделен строго под диски с операционными системами, то дедупликация высвободит 2\3 места (если не больше). На СХД есть возможность делать дедупликацию и сжатие на лету (опять же, с ограничениями). Или много. Сжатие может быть добавит еще немного. Или, если у вас пожатое видео, вообще ничего не добавит.

4 Вышеупомянутый тиринг — когда раз в сутки, на ваш выбор, или холодные данные уходят на дешевые медленные диски, или вдруг внезапно ставшие горячими данные уходят на SSD. 4.

Функция полезная, если применять с умом, грамотно настроить сбор статистики и следить за счетчиками.

5 Снапшоты на уровне СХД. 4.

Недооцениваемая мной ранее полезная вещь.

Как бекапится виртуальная машина целиком „обычно“ — делается снапшот, затем снапшот презентуется системе резервного копирования (СРК), после записи снапшота в СРК — система долго и нудно делает консолидацию.

При этом надо помнить, что неплохо бы внутри копируемой виртуальной машины иметь агент (сервис) системы резервного копирования, который скомандует прочим сервисам сбросить все что нажито на диск, отдать кошелек и вообще постоять (это Volume Shadow Copy Service, VSS в Windows).

Нужна эта служба для того чтобы, приложения (база данных и лог транзакций, или база Exchange и логи к ней) были в „скорее всего консистентном виде, хотя в статусе это вроде бы и не так“ (статус dirty для того же exchange), но по факту в памяти ничего не осталось, транзакции закрыты и новых нет, и можно будет быстро проверить журналы транзакций и дописать из них все, что нужно, если уж вдруг внезапно что-то пошло не так (что, конечно, не отменяет необходимость еще смотреть внимательно, как это работает с DAG и и Always On). Работа VSS — тема отдельного обсуждения.

Снапшот на уровне СХД не отменяет необходимость иметь агента в системе, или (как кажется у Veeam) скопировать мелкое приложение в систему и запустить его в момент запуска, но позволяет сократить время существования снапшота в среде виртуализации.

Как это работает.

ausweis.
Система резервного копирования делает снапшот виртуальной машины.
Система резервного копирования делает снапшот LUN от СХД (если умеет, конечно, и СХД поддерживает эту функцию. Система резервного копирования активирует тайного агента.
Агент системы резервного копирования делает командует приложению Halt! С Nimble тоже интеграция была, но какая именно — я не помню. Veeam + 3par поддерживают эту функцию уже давно, Veeam + Huawei — с лета 2018
Аналогично с IBM, точнее IBM Storwize.

Читайте сайт Veeam, у них отличная русская поддержка.

и запускает удаление снапшота. Когда снапшот сделан уже на СХД, СРК командует среде виртуализации Weggetreten! В результате нет длительного ожидания „пока у нас СРК вытащит снапшот“ и потом „когда же у нас пройдет консолидация“, а виртуалка работает дальше. В результате у нас есть снапшот на СХД (средствами СХД и более-менее целый с точки зрения консистентности данных) и есть быстро удаленный снапшот в среде виртуализации.

Конечно, данные затем будут забираться уже с СХД, и на этапе сбора сильного выигрыша в скорости не будет, но это уже будет гораздо быстрее в целом, за счет работы и оптимизированных кешей на чтение, и того что система будет писать свой снапшот туда, где ей удобней и быстрее, а это может оказаться и SSD (но это не точно, надо лезть в документацию), да и консолидация будет быстрее в пару раз (это тоже не точно)

6 Разнообразные операции миграции, перепрезентации и так далее. 4.

Новых дисков нет, поддержки нет, умрет контроллер — вообще будет беда. Допустим, у вас есть старая СХД (как у коллег), и ей скоро на заслуженный отдых. Есть два пути миграции
— средствами системы виртуализации делаем Live (или dead) migration.

Все хорошо, данные переедут рано или поздно, но это все равно снапшоты и последующая консолидация.

— Можно сделать иначе, можно скомандовать новому хранилищу „хватай и тащи“ (не для всех типов СХД и еще вопрос в лицензиях).

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

Работает тоже не для всех и не всегда, не для всех пар массивов и много чего еще „не“, ограничений полно.

7 Кеширование операций чтения на SSD дисках. 4.

Иногда же модель нагрузки такова, что нужно на большом СХД отдать кому-то много-много кеша на чтение. У контроллеров на СХД есть свой кеш, он быстрый и полезный, однако не очень большой — десятки, может сотни гигабайт. Есть такая возможность, отдаем SSD диск под кеш и радуемся.

Такое решение, в сочетании с быстрым процессором на отдельном тонком (1U) сервере, или даже отдельной выделенном специальном считательном лезвии с быстрыми (по МГц на ядро ) процессорами типа Intel Xeon Scalable
например Intel Xeon Platinum 8156 Processor (3. Немного отклоняясь от темы. 7 Ггц, 105 W TDP) или Intel Xeon Gold 5122 Processor, позволит получить хорошую выделенную числодробилку для больших баз, той же 1с.
Если же денег много, то можно еще и в лезвие поставить 2 SSD или 4 m2, собрать там raid 1/5/6 (если много смелости, то можно и 0), и будет убервундер 1с-лезвие, только бы памяти хватило и база бекапилась часто (впрочем, слотов в обычном лезвии уже 16-24, а в полноразмерном и побольше, что позволяет набить в одно лезвие по паре терабайт). 6 / 3.

8 Запуск виртуальных машин прямо на СХД. 4.

Функция слегка странная, но в некоторых сценариях (то же видеонаблюдение) может и полезная.
Управляющая часть СХД — обычный x86 сервер, памяти и процессоров там много, так что почему бы не запустить какой-то простой сервис „прямо там“.

9 Прочие функции. 4.

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

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

10 Стирание 4.

Иногда надо сделать так, чтобы данные были полностью уничтожены, однако диски при этом жалко.

Функция конечно имеет ограниченную применяемость, применима не ко всем типов дисков и LUN, и, конечно, уступает такой полезной функции как „расплавить в мартене домне современной дуговой печи“. В массивах, кроме шифрования (разного), есть и функция „стереть совсем“.

Обратная сторона функции: если у вас вдруг есть такой массив, нет оффлайн резервного копирования (по классике, 3-2-1, 3 копии, на двух типах носителей, 1 копия вне основной площадки) и у злых хацкеров (или вдруг заболевшего на всю голову админа) есть доступ к этой функции — есть риск потерять все и сразу.

11. 4. Делегирование, интеграция с LDAP и прочая.

Можно смело отдать Биг Боссу прав „на просмотр“, пусть смотрит на картинки, если ему надо. Само собой, есть функции „дать права на посмотреть кому-то“ с достаточно высокой гранулярностью, плюс красивые графики и нескучные картинки. Не сломает.

Куда это все развивается. 6.

SSD диски подешевели в последние 5 лет в разы, если не десятки раз (на гигабайт), увеличили скорость, живучесть, варианты подключения. СХД сейчас развиваются в двух направлениях — это гиперконвергентные програмно-аппаратные комплексы (ПАК), и all-flash массивы. Как итог — дисков 15к уже почти нет (купить конечно еще можно), диски 10к уже на подходе к ценовому рубежу, диски 7200 поживут еще.

Чипы (ASIC) и обработка в них тоже не стоят на месте.

Я, к примеру, „прямо сейчас“ качаю свежий Nutanix CE, и завтра собираюсь в магазин за парочкой SSD, просто чтобы дома посмотреть. Вывод — чтобы на новом месте не сидеть с удивленным видом, матчасть стоит изучить уже сейчас, хотя бы поверхностно.

Цены на диски, или „почему SSD вытеснили 15к“

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

92 TB, SAS, read intensive, digitally signed FW, solid state — 2700$.
875492-B21 HPE 960 GB, SATA, mixed used, digitally signed FW, solid state, M. В табличке могла быть еще и цена „за тышшу IOPS“ и „за гигабайт“.
872392-B21 HPE 1. 2 2280 — 1200$
870759-B21 — HPE 900 GB SAS, enterprise, 15K rpm, small form factor hard disk drive — 900$
702505-001 Жесткий диск HP 900GB SAS SFF 10K — порядка 400$

Немного выводов. 7.

Тут же возникает необходимость понимать теорию — что такое IOPS, latency (и где и от чего она возникает), raid penalty, профиль нагрузки (дневной, ночной, во время резервного копирования). Необходимость в понимании СХД возникает с того момента, когда бизнес начинает интересоваться „а почему у нас все так медленно“, и вы не находитесь, что ответить.

Комментарий от коллег:
Либо когда начинает интересоваться, „а как бы нам получить uptime на пять девяток, да задёшево?“

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

Пример RPO/RTO из жизни мелкого бизнеса: бухгалтеру было лень нажимать значок „RDP“ и 1С переехала с сервера (SSD raid 1, hdd raid 1 для резервных копий) на локальный компьютер, тоже с SSD.

Сдача отчетов в налоговую через неделю. Вчера оптимизаторы понесли SSD на восстановление, последняя резервная копия — 2 недели назад. Если не повезет, то рассказывать „у нас кошка сьела домашнюю работу“, будут уже в налоговой. Цена вопроса только восстановления — порядка 30 тысяч рублей, если повезет.

Если бизнесу это все еще не интересно в относительно точных цифрах, если оценка массива идет как „ну мы файл скопировали слева-направо, 100 Мб показало“ — значит не интересно, что же тут поделать.

8, может быть сдать экзамен и сменить работу на более денежную. Вернее, что поделать как раз известно — прочитать и сделать что говорят по ссылкам в пп. Хотя, если работа у дома, зарплата устраивает, то можно и не делать.

Ссылкота и что еще поискать 8.

На русском. Главная книга» Nutanix — http://nutanix.ru/ — очень полезная обзорная (и потом уже не только обзорная) книга «как это работает».

Что уже умеют промышленные СХД. Доклад Highload 2016.

Brocade: FC 101-WBT Introduction to Fibre Channel Concepts
Раз, два, три, четыре, пять.

Системы хранения данных Huawei Oceanstor V3
Системы хранения данных Huawei Oceanstor V3 (часть 2)
Системы хранения данных Huawei Oceanstor V3 (часть 3)
Системы хранения данных Huawei Oceanstor V3 (часть 4)

Huawei Storage Simulator

Это мелкий веб-сервер (сотни мегабайт), который позволяет у вас сделать виртуальную СХД. На удивление удобная штука. Подцепить ее конечно никуда нельзя, а вот понажимать всякие кнопочки, создать-снести дисковый домен, LUN и все что угодно, изучить логи и отдельно изучить командную строку — вполне можно.

Ссылки
там брать файлы вида «Demo_for_».

Huawei Hands-on LAB — например
Huawei Dorado 5000 V3 Storage Active-Active Solution(Carrier/Enterprise)

400 рублей без НДС (а сами между тем НДС потом приписывают, что вызывает опрежеденные проблемы при проведении, и особенно при возврате). H6LH3AAE Managing HPE 3PAR StoreServ Hands On Lab
Это курс от HPE, за который хотят 23.

HPE 3PAR StoreServ Simulator
h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?productNumber=HP3PARSIM

Что еще поискать.

HK902S Managing HPE 3PAR StoreServ I: Management and Local Replication (есть видео в интернетах)
HK904S Managing HPE 3PAR StoreServ II: Optimization and Remote Replication (аналогично, есть видео)

EMC Information Storage and Management Student Guide (это книжка не на русском)

Vdisks, Mdisks, Extents and Grains — Scale Out for Sure


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Введение в ptrace или инъекция кода в sshd ради веселья

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

Дайджест свежих материалов из мира фронтенда за последнюю неделю №339 (12 — 18 ноября 2018)

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.     Медиа    |    Веб-разработка    |    CSS    |    Javascript    |    Браузеры    |    Занимательное Медиа • Подкаст «Frontend Weekend» #79 – Олег Поляков об основании CodeDojo и о том, как это стало основным местом работы• Подкаст «Пятиминутка React» ...