Что умеет СХД — или старые песни о главном
Пару дней назад позвонили мне коллеги с вопросом — старая дисковая полка совсем умирает (у них старый еще IBM), чего делать? Дисков нет, поддержки нет, денег нет зовут Олег.
Что покупать, куда бежать, как дальше жить?
На хабре же, кроме отсутствия кнопки «вставить таблицу» и смешения (после слияния с GT) в одну кучу философии, политики, школьной космонавтики и осеннего обострения, имеется еще и почти полное отсутствие присутствия свежих статей про то, как работает современная СХД, чего выбирать в этом сезоне и так далее.
Новых авторов тоже что-то нет, про, скажем, 3par с 2015 года почти ни слова (зато, внезапно, нашелся материал по Huawei Oceanstor — так что будет много ссылок про него).
Придется написать мне, как умею — чтобы было чего коллегам рассказать про СХД, и на что ссылаться.
TL/DR Что там творится в СХД «сейчас». Кратко и с ошибками, в присущем автору стиле «валим в кучу».
Итак, что умеют современные СХД из разряда «дорого конечно, но выбора особо нет».
1. Младшие системы хранения
1.1. Системы уровня «сделай сам».
1.2. То же самое, но с завода и с обновлениями от производителя.
1.3. Младшие всамделишные СХД. Уже с перламутровыми пуговицами.
2. Гиперконвергентные системы хранения.
3. Системы на базе Ceph, Gluster и так далее.
4. Современные СХД среднего ценового сегмента.
5. Современные СХД старшего ценового сегмента не будут рассмотрены, хотя там тоже интересно.
6. Куда это все развивается.
7. Немного выводов.
8. Ссылкота и что еще поискать и почитать, в том числе на русском.
1. Младшие системы хранения
1.1. Системы уровня «сделай сам».
Ничего сложного в этом нет — взяли любой контроллер SAS дисков, или даже без него, взяли любой корпус «побольше», набили туда дисков, собрали из них Raid 1–10–5–6, и отдали по 10G iSCSI. Windows умеет собирать програмный Raid 5 с времен Server 2003, и отдавать его по iSCSI тоже где-то с Server 2003. Linux тоже умеет и raid, и iSCSI target, процесс настройки описан, я делал.
Проблемы у такого самосбора есть во всем, начиная от скорости работы самого массива, заканчивая мониторингом (SNMP нет, контроллер ничего не умеет, а агент Zabbix ставить надо), скоростью перестроения и различными аппаратно-программными фокусами в работе.
Комментарий от коллег:
Ну кстати зря, FreeNAS даст всё из коробки. Внизу будет ZFS, ну так каждый злобный буратино сам выбирает чем себя развлечь.
И скорость вполне цивильная, десяток 900gb 10k вполне тянул средненький бузинес (Экс ~ 100 рыл с жирными ящиками, Шарик, терминалы и прочая мишура). Raid-10 конечно, Storage Spaces, JBOD полка SS и головы на DL120g8.
Вообще, самое на мой взгляд больное место современных простых массивов — это скорость перестроения Raid 5–6 на емких и дешевых дисках 7200 SATA / NL-SAS.
Причина этой боли известна — чтобы построить выпавший блок, надо прочитать все блоки из оставшихся, посчитать выпавший блок, и записать этот блок, с учетом Raid penalty и того что остальные то диски продолжают работать. Перестроение такого массива может идти 3 дня, а может и неделю, и нагружены будут все диски, причем так, как они обычно не нагружаются.
Второй и ТРЕТИЙ диск у меня при таких ребилдах вылетали, иногда приходилось данные брать из бекапа.
Решения вида «а давайте соберем не 6, а 60» приводит к легкой форме амфибийной асфикции (удушения жабой). Например, у нас массив из 24 дисков, без диска горячей замены (в шкафу лежит). Разбиваем его на 3 блока по 6+2 диска, собираем R60 и получаем свободной емкости »-2 с каждого блока, всего -6». Это конечно не -12 от Raid10, но уже стремительно к нему приближается.
Да, и не все контроллеры поддерживают Raid60, да и на 6–8 Тб дисках все равно будет грустно.
1.1a. Отдельно надо отметить решение «как бы непойми что» — это например вот такое.
Ни слова о том, что за ноды, что за контроллеры, что с снапшотами и бекапами, что там за «ну у нас не x86 в базе» —, а что, малинка? или какой ARM?, и намеки на полные потери данных в комментариях.
1.2. То же самое, но с завода и с обновлениями от производителя.
Это младшие QNap, Synology, кто там еще. Не совсем уж самые младшие «для дома — SOHO», с ZFS и неонкой, а что-то похожее на СХД.
В таких СХД уже два блока питания, два контроллера SAS подороже, две сетевые карты 10G, или даже может быть FC 8/16, и все, что сверху определено програмно — хотите iSCSI, хотите SMB (а если вы смелый, то даже и SMB 1.0), хотите NFS, можно FTP. Хотите — даже можно тонкие диски сделать. На контроллере даже кеш с батарейкой имеется! Конечно, это не такая большая батарейка, чтобы джва часа крутить диски, но есть.
Система хорошая, рабочая —, но проблемы те же, что и у самосбора. Скорость и ребилд. И да, при обновлении будет перерыв в работе минут на 30 (если ОС) или на пару часов (если еще и FW контроллеров), и часто откатиться нельзя.
Сверху добавлены глюки как «от производителя», так и от того, что под капотом у такой СХД, какой контроллер и ОС.
1.3. Младшие всамделишные СХД. Уже с перламутровыми пуговицами.
То, что в книжка с картинками называется «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 здесь все те же, и добавляются новые — с тем же тирингом.
Что такое тиринг, я надеюсь, все знают. Если не знают, то
Тиринг:
это объединение в одну группу хранения 2–3 типов разных дисков и типов Raid, например — собираем в одну группу SSD в Raid 10, и SATA 7200 в Raid 6 / 60. После чего у нас СХД смотрит (пару суток), к каким данным чаще обращались (горячие данные), и оставляет их на SSD, а более «холодные» отправляет на уровень ниже. В результате горячие данные лежат на SSD, совсем холодные на дешевых SATA 7200. Вот только перестроение идет раз в сутки, а иногда надо «сейчас». Массив не оперирует отдельными файлами виртуальных машин, поэтому ускорить «одну машину туда прямо сейчас» не выйдет, разве что имея в запасе гарантированно быстрый отдельный LUN, и перебросив машину (из среды виртуализации) на него или вообще на локальные хранилища хоста виртуализации.
Новые, свежие проблемы и боли начинаются примерно здесь, причем проблемы не с СХД. Простой пример — СХД куплено «задорого», а потом к ней запускают горе-специалистов из (от) того же Гилева, и они начинают в среде виртуализации гонять CrystalDiskMark, чтобы попробовать получить на выходе скорость чтения на уровне самого медленного уровня хранения. Зачем они так делают — не понятно совсем.
Впрочем, кто допускает в свою инфраструктуру таких горе-спецов, оплачивает весь этот труд своими деньгами, это их право. Как говорится, чего только люди не сделают, вместо покупки нового сервера 1U с быстрыми процессорами и многопамяти «только под 1с» — например с
Intel Xeon Gold 5122(3.6GHz/4-core/16.5MB/105W) Processor
или Intel Xeon Platinum 8156(3.6GHz/4-core/16.5MB/105W) Processor
Кстати, надо будет и себе такое чудо под 1с попросить прикупить — денег нет, но запрос цен на Dell/Lenovo/Huawei/HPE пожалуй сделаю.
2. Гиперконвергентные системы хранения.
Это совсем не младший сегмент, особенно Nutanix, однако, учитывая повсеместную горячую любовь к импортозамещению «по трофейному», и наличие Nutanix CE (у некоторых даже и в продуктиве), то придется разместить тут.
Проще говоря, гиперконвергентность — это сервер набивается дисками и SSD, и рабочие данные лежат локально на тех же серверах, где и работают виртуальные машины (а копия — где-то еще).
Из широко известных систем это Nutanix (целиком, как програмно-аппаратный комплекс, хотя есть и CE «на посмотреть»), MS Storage space direct (S2D), VMWare VSAN. С последним все очень весело, система называется «ни дня без патчей», «мы опять страдаем», или, как c последним обновлением 6.7u1 — «мы сломали вам бекап, МВУ ХО ХО».
Не то чтобы у остальных этого не было, проблемы есть у всех, просто я чаще сталкиваюсь именно с VMWare.
Ряд производителей (кроме самого Nutanix) уже продает такие системы — к примеру Dell XC Series.
В целом у этих систем мне кажется что все неплохо. У всех. И MS активно продается (причем даже в формате Azure stack — уже две штуки в РФ), и Nutanix растет и по продажам, и по капитализации, и выигрыш в скорости работы в некоторых сценариях у Nutanix порядочный, реально «в разы», вплоть до роста скорости работы некоторых сервисов по обсчету фотографий с 5 часов до часа (если не быстрее). Даже дедупликация с компрессией имеется.
Судя по финансовым показателям, у VMWare в целом пока тоже все неплохо.
3. Системы на базе Ceph, Gluster и так далее.
Можно что-то подобное собрать и на open source компонентах, особенно если вы смелый, и (или) у вас есть штат разработчиков, как в Кроке. Или данные не жалко. Конечно, такого как в Cloud Mouse больше не будет, что вы что вы. Или может просто фарту масти.
примеры раз
примеры два
примеры три
Проблемы с внедрением таких решений есть:
- технические:, а как это все бекапить? И сколько будет перестраиваться при отказе одного диска или одной машины? Как правильно настраивать и кто будет поддерживать? А сколько займет восстановление?
- административные: А если ваш администратор попадет под трамвай или просто уволится, то кто и почем возьмется за поддержку? Сколько это будет стоить? А если вы вдруг потеряете вашу роскошную команду разработчиков в полном составе? Конечно, это не связка ключей, но бывает что люди уходят сразу командами.
Комментарий от коллег:
А что будет при блэкауте? А то есть прохладная история, как упавшая Симметра уронила ЦОД в одном ФГУПе ©. Упавшая в прямом смысле, фальшпол провалился.
Как и весёлые сварщики в другом ФГУПе, показавшие капиталистическому инвертору суровое русско-таджикское «Ага!».
Так что, как это всё будет заводиться и чиниться, при 100500k IOPS записи в секунду при падении — вопрос.
А если вы не в Дефолт Сити, а в каких-нить хибинях, среди медведей и комаров? Медведя можно научить играть на балалайке, а вот глюстер чинить…
В среднего уровня СХД, к слову, стоят и батарейки на кеш (или суперконденсаторы), или целиком свои батарейные модули, да и сам кеш тоже частично в RAM, а частично в SSD и при провале питания всего ЦОД — аккуратно переложит все что не успел — в журналы транзакций и в свой резервированный кеш.
НО БЕКАП ДЕЛАТЬ ВСЕ РАВНО НАДО.
4. Современные СХД среднего ценового сегмента.
Как я уже писал, поиском по хабру быстренько нашлось три статьи про Huawei OceanStor
Импортозамещение Часть 2. Huawei OceanStor Family, три строки вот тут
и тестирование All-flash OceanStor Dorado V3 .
Есть парочка обзоров 2012–2015 года по 3par
пример
Обзоров по Dell, IBM Storwize я как-то не искал, может и зря.
В большом интернете материалов на русском чуть больше, например тот же Oceanstor рассмотрен тут (кстати, в целом полезный бложек, набит ссылкотой по Huawei).
Итак, что нам предлагает современный массив уровня HPE 3par / Huawei / IBM-Lenovo.
4.1 В первую очередь, это новый подход к разбиению дисков. Это 3Par RAID, Huawei Raid 2.0 и у Lenovo-IBM это Storwize Distributed RAID (DRAID). Зачатки этого по слухам были еще в HP Enterprise Virtual Array (EVA), в 3Par пришло к логичному и более-менее понятному состоянию.
Как это работает. Вообще есть видео, хотя и на английском, но все понятно.
HPE 3PAR StoreServ Architecture Overview ChalkTalk
Huawei RAID 2.0 Technology
Или (подольше, подробнее и на русском) — Вебинар E=DC2 №2: Технология RAID и её применение — про Raid 2.0 с 1:18.
Как это работает, если описывать словами, а не картинками.
Сначала мы выделяем дисковый домен. Просто группа дисков, разных — например, SSD и SATA.
Каждый отдельный диск разбивается на логические блоки по 64/256/1Гб (у всех по разному), называемые тоже по разному. У HPE это chunklets, у Huawei chunk, у IBM — extent (но это не точно).
Потом уже из этих chunklets\chunk (не из всех сразу! А из не более N, массив R5 из 50+1 вы несеберете, и размазанных по разным дискам!), chunklets\chunk должны быть одинакового типа (например SSD), емкость дисков и их количество к слову тоже регламентировано, типа «диски одинаковые, добавлять парами — 2,4) собираем массив «какой нам нужен». Например на SSD нам нужна скорость — собираем R10, а на SATA важен объем — собираем Raid 5. Точнее не «собираем», а выбираем «как нам тут собрать». Никаких 100500 ручных операций тут нет. Полученные chunklets\chunk group собираются в группы, группы нарезаются мелкими секторами (под тиринг), жучка за внучку, и в итоге получаем тонкий или толстый логический диск (уже LUN или файловая система под SMB), нужного размера плюс зарезервированное пространство «под ребилд». Детально можно посмотреть например тут.
Какие плюсы от такого подхода к разбиению.
Плюсы достаточно простые.
В первую очередь, это гораздо более быстрое перестроение при сбое одного диска.
ВНИМАНИЕ! Бекапы делать все равно надо! Raid — не бекап, и не защитит от некорректного изменения данных никак.
Если при сбое диска в Raid5/6 нам надо было прочитать все данные, посчитать математику и записать все данные на один диск, то узким местом становился сам результирующий диск.
Здесь же запись будет идти на все диски сразу. Тут конечно надо бы рассмотреть такой функционал, как запись полными страйпами, но этим сейчас сложно кого-то удивить.
В результате перестроение идет в разы быстрее.
Как это работает с точки зрения математики и Raid.
Спешу всех успокоить, магии тут нет. Raid никуда не делся, просто стал немножко более виртуальным.
Пусть у нас 2 массива на 20 дисков. и +запасные в каждом. 1,2 — не важно.
Диски разные, но суммарный сырой объем массива одинаков.
Первый массив собран из дисков по 2Тб как Raid 5. 19+1.
Второй массив собран из дисков по 1Тб как Raid 50. 4 группы Raid 5 по 5 дисков собраны в raid-группу. Итого (4+1)*4
Пусть у нас вылетает по суммарному объему в 2 Тб в каждом случае. В разных дисковых группах для второго массива.
В первом случае нам надо прочитать данные с 19 оставшихся дисков, посчитать «что было потеряно» и записать на 1 диск. Скорость записи на один диск будет — пусть 10 IOPS (у нас штрафы на raid не отменены и есть прочая нагрузка).
Во втором случае нам надо прочитать данные только с 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 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. The following logical disk types are created by the system:
• logging logical disks are RAID 10 logical disks that are used to temporarily hold data during
disk failures and disk replacement procedures. Logging logical disks are created by the system
during the initial installation and setup of the system. Each controller node in the system has
a 60 GB logging LD.
How spare chunklets work:
• 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. Logging disk space is allocated when the
system is set up. This does not apply to RAID 0 chunklets which have no fault-tolerance.
• 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.2.4 Concepts Guide
4.2 Кроме быстрого перестроения, такое разбиение добавляет возможности делать всякое удобное в формате «тонких дисков». В принципе, это умеет делать и Microsoft, и Vmware, но оба с своими интересными особенностями в плане скорости. Тут, за счет кешей и предварительного выделения места «про запас», проблем чуть меньше.
4.3 Дедупликация и сжатие.
Та же дедупликация уже давно есть на NTFS, и недавно появилась на ReFS, но работает не всегда понятным мне образом, оффлайн и по расписанию.
На СХД есть возможность делать дедупликацию и сжатие на лету (опять же, с ограничениями). Если у вас данные «похожие, а то и такие же», например какой-то LUN выделен строго под диски с операционными системами, то дедупликация высвободит 2\3 места (если не больше). Сжатие может быть добавит еще немного. Или много. Или, если у вас пожатое видео, вообще ничего не добавит.
4.4 Вышеупомянутый тиринг — когда раз в сутки, на ваш выбор, или холодные данные уходят на дешевые медленные диски, или вдруг внезапно ставшие горячими данные уходят на SSD.
Функция полезная, если применять с умом, грамотно настроить сбор статистики и следить за счетчиками.
4.5 Снапшоты на уровне СХД.
Недооцениваемая мной ранее полезная вещь.
Как бекапится виртуальная машина целиком «обычно» — делается снапшот, затем снапшот презентуется системе резервного копирования (СРК), после записи снапшота в СРК — система долго и нудно делает консолидацию.
При этом надо помнить, что неплохо бы внутри копируемой виртуальной машины иметь агент (сервис) системы резервного копирования, который скомандует прочим сервисам сбросить все что нажито на диск, отдать кошелек и вообще постоять (это Volume Shadow Copy Service, VSS в Windows).
Работа VSS — тема отдельного обсуждения. Нужна эта служба для того чтобы, приложения (база данных и лог транзакций, или база Exchange и логи к ней) были в »скорее всего консистентном виде, хотя в статусе это вроде бы и не так» (статус dirty для того же exchange), но по факту в памяти ничего не осталось, транзакции закрыты и новых нет, и можно будет быстро проверить журналы транзакций и дописать из них все, что нужно, если уж вдруг внезапно что-то пошло не так (что, конечно, не отменяет необходимость еще смотреть внимательно, как это работает с DAG и и Always On).
Снапшот на уровне СХД не отменяет необходимость иметь агента в системе, или (как кажется у Veeam) скопировать мелкое приложение в систему и запустить его в момент запуска, но позволяет сократить время существования снапшота в среде виртуализации.
Как это работает.
Система резервного копирования активирует тайного агента.
Агент системы резервного копирования делает командует приложению Halt! ausweis.
Система резервного копирования делает снапшот виртуальной машины.
Система резервного копирования делает снапшот LUN от СХД (если умеет, конечно, и СХД поддерживает эту функцию. Veeam + 3par поддерживают эту функцию уже давно, Veeam + Huawei — с лета 2018
Аналогично с IBM, точнее IBM Storwize. С Nimble тоже интеграция была, но какая именно — я не помню.
Читайте сайт Veeam, у них отличная русская поддержка.
Когда снапшот сделан уже на СХД, СРК командует среде виртуализации Weggetreten! и запускает удаление снапшота. В результате у нас есть снапшот на СХД (средствами СХД и более-менее целый с точки зрения консистентности данных) и есть быстро удаленный снапшот в среде виртуализации. В результате нет длительного ожидания «пока у нас СРК вытащит снапшот» и потом «когда же у нас пройдет консолидация», а виртуалка работает дальше.
Конечно, данные затем будут забираться уже с СХД, и на этапе сбора сильного выигрыша в скорости не будет, но это уже будет гораздо быстрее в целом, за счет работы и оптимизированных кешей на чтение, и того что система будет писать свой снапшот туда, где ей удобней и быстрее, а это может оказаться и SSD (но это не точно, надо лезть в документацию), да и консолидация будет быстрее в пару раз (это тоже не точно)
4.6 Разнообразные операции миграции, перепрезентации и так далее.
Допустим, у вас есть старая СХД (как у коллег), и ей скоро на заслуженный отдых. Новых дисков нет, поддержки нет, умрет контроллер — вообще будет беда. Есть два пути миграции
— средствами системы виртуализации делаем Live (или dead) migration.
Все хорошо, данные переедут рано или поздно, но это все равно снапшоты и последующая консолидация.
— Можно сделать иначе, можно скомандовать новому хранилищу «хватай и тащи» (не для всех типов СХД и еще вопрос в лицензиях).
В результате нужные данные переедут в фоновом режиме, и затем старый LUN будет показан как «как бы вот он тут всегда и был и ничего не было», хотя по факту данные будут уже на новом СХД.
При этом можно сделать так, чтобы старое СХД тоже не пропадало, и хранить данные частично на нем, чего добру и терабайтам пропадать.
Работает тоже не для всех и не всегда, не для всех пар массивов и много чего еще «не», ограничений полно.
4.7 Кеширование операций чтения на SSD дисках.
У контроллеров на СХД есть свой кеш, он быстрый и полезный, однако не очень большой — десятки, может сотни гигабайт. Иногда же модель нагрузки такова, что нужно на большом СХД отдать кому-то много-много кеша на чтение. Есть такая возможность, отдаем SSD диск под кеш и радуемся.
Немного отклоняясь от темы. Такое решение, в сочетании с быстрым процессором на отдельном тонком (1U) сервере, или даже отдельной выделенном специальном считательном лезвии с быстрыми (по МГц на ядро) процессорами типа Intel Xeon Scalable
например Intel Xeon Platinum 8156 Processor (3.6 / 3.7 Ггц, 105 W TDP) или Intel Xeon Gold 5122 Processor, позволит получить хорошую выделенную числодробилку для больших баз, той же 1с.
Если же денег много, то можно еще и в лезвие поставить 2 SSD или 4 m2, собрать там raid 1/5/6 (если много смелости, то можно и 0), и будет убервундер 1с-лезвие, только бы памяти хватило и база бекапилась часто (впрочем, слотов в обычном лезвии уже 16–24, а в полноразмерном и побольше, что позволяет набить в одно лезвие по паре терабайт).
4.8 Запуск виртуальных машин прямо на СХД.
Функция слегка странная, но в некоторых сценариях (то же видеонаблюдение) может и полезная.
Управляющая часть СХД — обычный x86 сервер, памяти и процессоров там много, так что почему бы не запустить какой-то простой сервис «прямо там».
4.9 Прочие функции.
Это разнообразные репликации, синхронные, асинхронные, метрокластера и так далее.
С ними все уже неплохо даже у средних СХД, но те, у кого два разнесенных датацентра, это и так знают в разы лучше меня.
Хотя, если у вас есть желание сделать тайную комнату (василиск приобретается и лицензируется отдельно) на случай прихода незванных гостей, поставить туда вторую СХД (попроще) и хранить там копию данных — то эта возможность есть.
4.10 Стирание
Иногда надо сделать так, чтобы данные были полностью уничтожены, однако диски при этом жалко.
В массивах, кроме шифрования (разного), есть и функция «стереть совсем». Функция конечно имеет ограниченную применяемость, применима не ко всем типов дисков и LUN, и, конечно, уступает такой полезной функции как «расплавить в мартене домне современной дуговой печи».
Обратная сторона функции: если у вас вдруг есть такой массив, нет оффлайн резервного копирования (по классике, 3–2–1, 3 копии, на двух типах носителей, 1 копия вне основной площадки) и у злых хацкеров (или вдруг заболевшего на всю голову админа) есть доступ к этой функции — есть риск потерять все и сразу.
4.11. Делегирование, интеграция с LDAP и прочая.
Само собой, есть функции «дать права на посмотреть кому-то» с достаточно высокой гранулярностью, плюс красивые графики и нескучные картинки. Можно смело отдать Биг Боссу прав «на просмотр», пусть смотрит на картинки, если ему надо. Не сломает.
6. Куда это все развивается.
СХД сейчас развиваются в двух направлениях — это гиперконвергентные програмно-аппаратные комплексы (ПАК), и all-flash массивы. SSD диски подешевели в последние 5 лет в разы, если не десятки раз (на гигабайт), увеличили скорость, живучесть, варианты подключения. Как итог — дисков 15к уже почти нет (купить конечно еще можно), диски 10к уже на подходе к ценовому рубежу, диски 7200 поживут еще.
Чипы (ASIC) и обработка в них тоже не стоят на месте.
Вывод — чтобы на новом месте не сидеть с удивленным видом, матчасть стоит изучить уже сейчас, хотя бы поверхностно. Я, к примеру, «прямо сейчас» качаю свежий Nutanix CE, и завтра собираюсь в магазин за парочкой SSD, просто чтобы дома посмотреть.
Цены на диски, или «почему SSD вытеснили 15к»
Тут могла быть табличка, но руками мне ее делать и проверять лень, кнопки вставки таблиц нет и видимо не будет.
В табличке могла быть еще и цена «за тышшу IOPS» и «за гигабайт».
872392-B21 HPE 1.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.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)
H6LH3AAE Managing HPE 3PAR StoreServ Hands On Lab
Это курс от HPE, за который хотят 23.400 рублей без НДС (а сами между тем НДС потом приписывают, что вызывает опрежеденные проблемы при проведении, и особенно при возврате).
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
