![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
scif_yarЧто умеет СХД - или старые песни о главном.
Пару дней назад позвонили мне коллеги с вопросом - старая дисковая полка совсем умирает ( у них старый еще 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.
Проблемы у такого самосбора есть во всем, начиная от скорости работы самого массива, заканчивая мониторингом, скоростью перестроения и различными аппаратно-программными фокусами.
Вообще, самое на мой взгляд больное место современных простых массивов - это скорость перестроения 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. Отдельно надо отметить решение "как бы непойми что" - это например вот такое
https://habr.com/company/tssolution/blog/425309/
Ни слова о том, что за ноды, что за контроллеры, что с снапшотами и бекапами, что там за "ну у нас не x86 в базе", и две полные потери данных в комментариях.
1.2. То же самое, но с завода и с обновлениями от производителя.
Это младшие QNap, Synology, кто там еще.
В таких СХД уже два блока питания, два контроллера SAS уровнем подороже, две сетевые карты 10G, или даже может быть FC 8/16, и все что сверху определено програмно - хотите iSCSI, хотите SMB (а если вы смелый, то даже и SMB 1.0), хотите NFS, можно FTP. Хотите - даже можно тонкие диски сделать. На контроллере даже кеш с батарейкой имеется!
Система хорошая, рабочая - но проблемы те же. И да, при обновлении будет перерыв в работе минут на 30 (если ОС) или на пару часов (если еще и FW контроллеров), и часто откатиться нельзя.
Сверху добавлены глюки как "от производителя", так и от того, что под капотом у такой СХД, какой контроллер и ОС.
1.3. Младшие всамделишные СХД. Уже с перламутровыми пуговицами.
Из известных это линейка HPE MSA - 2052, 2050, 2042, 2040, 1050, 1040, P2000 G3.
Dell конечно, да и Lenovo, старые Huawei
К примеру, сейчас старое (4-е) поколение линейки HPE MSA заканчивает жизненный цикл, как скромно пишут на сайте HPE - покупайте 1040 -> 1050, 2040 -> 2050, 2042 -> 2052.
Notice: HPE MSA 1040, 2040, 2042 SAN Storage - End Of Life Announcement
Release Date: 2017-12-11
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00038415en_us&docLocale=en_US
На этом уровне появляются такие функции, как апгрейд прошивки контроллера без перерыва сервиса, возможность замены контроллера на следующее поколение, само собой "горячая замена всего" - дисков, контроллеров, блоков питания. Появляются снапшоты на уровне СХД, тиринг (tiering), и удаленная репликация. Почитать не по русски можно скажем тут -
HPE MSA 2050 SAN Storage - Overview
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00017538en_us#N10087
или тут HPE MSA 1050/2050/2052 Best Practices https://h20195.www2.hpe.com/v2/getpdf.aspx/A00015961ENW.pdf
или тут в переводе https://habr.com/company/hpe/blog/426063/
Проблемы с перестроением Raid здесь все те же, и добавляются новые - с тем же тирингом.
Что такое тиринг я надеюсь все знают. Если не знают, то это объединение в одну группу хранения 2-3 типов разных дисков и типов Raid, например собираем в одну группу SSD в Raid 10, и SATA 7200 в Raid 6 / 60. После чего у нас СХД смотрит, к каким данным чаще обращались (горячие данные), и оставляет их на SSD, а более "холодные" отправляет на уровень ниже. В результате горячие данные лежат на SSD, совсем холодные на дешевых SATA 7200, а "ну так сяк" - как повезет.
Новые, свежие проблемы и боли начинаются примерно здесь, причем проблемы не с СХД. Простой пример - СХД куплено "задорого", а потом к ней запускают горе-специалистов из(от) того же Гилева, и они начинают в среде виртуализации гонять 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
Пока правда денег нет, но запрос цен на Dell/Lenovo/Huawei/HPE пожалуй сделаю.
2. Гиперконвергентные системы хранения.
Это совсем не младший сегмент, особенно Nutanix, однако, учитывая повсеместную горячую любовь к импортозамещению "по трофейному", и наличие Nutanix CE (а у некоторых даже и в продуктиве), то придется разместить тут.
Проще говоря, гиперконвергентно - это сервер набивается дисками и SSD, и рабочие данные лежат локально на тех же серверах, где и работают виртуальные машины (а копия - где-то еще).
Из широко известных систем это Nutanix (целиком, как програмно-аппаратный комплекс, хотя есть и CE "на посмотреть"), MS Storage space direct (S2D), VMWare VSAN. С последним все очень весело, система называется "ни дня без патчей", "мы опять страдаем", или, как c последним обновлением 6.7u1 - "мы сломали вам бекап, МВУ ХО ХО".
Не то чтобы у остальных этого не было, проблемы есть у всех, просто я чаще сталкиваюсь именно с VMWare.
В целом у этих систем все неплохо. И MS активно продается (причем даже в формате Azure stack - уже две штуки в РФ), и Nutanix растет и по продажам, и по капитализации, и выигрыш в скорости работы в некоторых сценариях у Nutanix порядочный, реально "в разы", вплоть до роста скорости работы некоторых сервисов по обсчету фотографий с 5 часов до часа (если не быстрее). Даже дедупликация с компрессией имеется.
Судя по финансовым показателям, у VMWare в целом пока тоже все неплохо.
3. Системы на базе Ceph, Gluster и так далее.
Можно что-то подобное собрать и на open source компонентах, особенно если вы смелый, и (или) у вас есть штат разработчиков, как в Кроке. Или данные не жалко. Конечно, такого как в Cloud Mouse больше не будет, что вы что вы. Или может просто фарту масти.
примеры раз https://habr.com/company/semrush/blog/353854/
примеры два https://habr.com/company/croccloudteam/blog/422905/
примеры три https://habr.com/company/croccloudteam/blog/417475/
Проблема - а как это все бекапить? И сколько будет перестраиваться при отказе одного диска или одной машины? Как настраивать и кто будет поддерживать? А если ваш администратор попадет под трамвай или просто уволится, то кто и почем возьмется за поддержку?
4. Современные СХД среднего ценового сегмента.
На хабре, кроме недостатка кнопки "вставить таблицу" и смешения (после слияния с GT) в одну кучу философии, политики, школьной космонавтики и осеннего обострения, имеется еще и почти полное отсутствие присутствия свежих статей про то, как работает современная СХД. Жбанков и Шапошников не пишут, поиск работает так же как таблицы - про 3par с 2015 года почти ни слова.
Быстренько нашлось три статьи про Huawei OceanStor
Импортозамещение Часть 2. Huawei OceanStor Family https://habr.com/post/254593/
три строки вот тут https://habr.com/company/lanit/blog/335242/
и тестирование All-flash OceanStor Dorado V3 https://habr.com/company/croc/blog/350152/
и есть парочка обзоров 2012-2015 года по 3par
пример https://habr.com/company/muk/blog/263469/
В большом интернете материалов на русском чуть больше, например тот же Oceanstor рассмотрен тут
http://dendubinin.blogspot.com/2015/01/huawei-oceanstor-v3-2.html
(кстати, в целом полезный бложек, набит ссылкотой по Huawei).
Итак, что нам предлагает современный массив уровня HPE 3par / Huawei / IBM-Lenovo.
В первую очередь, это новый подход к разбиению дисков. Это 3Par RAID, Huawei Raid 2.0 и у Lenovo-IBM тоже как-то называется (Storwize Distributed RAID (DRAID) это называется). Зачатки этого по слухам были еще в HP Enterprise Virtual Array (EVA), в 3Par пришло к логичному и более-менее понятному состоянию.
Как это работает. Вообще есть видео, хотя и на английском, но все понятно. https://youtu.be/LMe1CTL5rDY
Сначала мы выделяем дисковый домен. Просто группа дисков и не более.
Каждый отдельный диск разбивается на логические блоки по 64/256/1Гб, называемые у кого как. У HPE это chunklets, у Huawei chunk, у IBM - extent, но это не точно.
Потом уже из этих chunklets\chunk собираем блок, блок в группу, жучка за внучку, и в итоге получаем тонкий или толстый логический диск плюс зарезервированное пространство.
Какие плюсы от такого подхода к разбиению.
Плюсы достаточно простые.
В первую очередь, это гораздо более быстрое перестроение при сбое одного диска.
Если при сбое диска в Raid6 нам надо было прочитать все данные, посчитать математику и записать все данные на один диск, то узким местом становился сам результирующий диск.
Здесь же запись будет идти на все диски сразу. Тут конечно надо бы рассмотреть такой функционал, как запись полными страйпами, но этим сейчас сложно кого-то удивить.
В результате перестроение идет в разы быстрее.
ВНИМАНИЕ! Бекапы делать все равно надо! Raid - не бекап, и не защитит от некорректного изменения данных никак.
В вторую, это возможность делать всякое удобное в формате "тонких дисков". В принципе, это умеет делать и Microsoft, и Vmware, но оба с своими интересными особенностями в плане скорости. Тут, за счет кешей и предварительного выделения места "про запас", проблем чуть меньше.
Дедупликация и сжатие.
Та же дедупликация уже давно есть на NTFS, и недавно появилась на ReFS, но работает не всегда понятным мне образом.
На СХД есть возможность делать дедупликацию и сжатие на лету. Если у вас данные "похожие, а то и такие же", например LUN выделен строго под диски с операционными системами, то дедупликация высвободит 2\3 места (если не больше). Сжатие может быть добавит еще немного. Или много. Или, если у вас пожатое видео, вообще ничего не добавит.
Вышеупомянутый тиринг - когда раз в сутки, на ваш выбор, или холодные данные уходят на дешевые медленные диски, или вдруг внезапно ставшие горячими данные уходят на SSD.
Функция полезная, если применять с умом.
Снапшоты на уровне СХД.
Недооцениваемая многими полезная вещь.
Как бекапится виртуальная машина целиком "обычно" - делается снапшот, затем снапшот презентуется системе резервного копирования (СРК), после записи диска - система долго и нудно делает консолидацию.
При этом надо помнить, что неплохо бы внутри копируемой виртуальной машины иметь агент (сервис) системы резервного копирования, который скомандует прочим сервисам сбросить все кеши на диск и вообще постоять (это Volume Shadow Copy Service, VSS в Windows), для того чтобы, хотя формально та же база данных и лог транзакций (или база Exchange и логи к ней) были в "скорее всего неконсистентном виде" (статус dirty для того же exchange), но по факту в памяти ничего не осталось, и можно было быстро проверить журналы транзакций и дописать из них все, что нужно.
Снапшот на уровне СХД не отменяет необходимость иметь агента в системе, или (как кажется у Veeam) скопировать мелкое приложение и запустить его в момент запуска, но позволяет сократить время существования снапшота в среде виртуализации.
Как это работает.
Сначала агент делает командует приложению Halt!ausweis.
Затем система резервного копирования делает снапшот виртуальной машины.
Затем система резервного копирования делает снапшот LUN от СХД (если умеет, конечно, и СХД поддерживает эту функцию. Veeam + 3par поддерживают эту функцию уже давно, Veeam + Huawei - с лета 2018
Пруф https://www.veeam.com/blog/intelligent-data-management-huawei-oceanstor.html
Аналогично с IBM, точнее IBM Storwize. С Nimble тоже интеграция была.
Читайте сайт Veeam, у них отличная русская поддержка.
Когда снапшот сделан уже на СХД, система командует Weggetreten! и запускает удаление снапшота. В результате у нас есть снапшот на СХД (средствами СХД и более-менее целый) и быстро удаленный снапшот в среде виртуализации. В результате нет длительного ожидания "пока у нас СРК вытащит снапшот" и потом "когда же у нас пройдет консолидация", а виртуалка работает дальше.
Конечно, данные затем будут забираться уже с СХД, и тут сильного выигрыша в скорости не будет, но это уже будет гораздо быстрее в целом, за счет работы и оптимизированных кешей на чтение, и того что система будет писать свой снапшот туда, где ей удобней и быстрее, а это может оказаться и SSD (но это не точно), да и консолидация будет быстрее в пару раз (это тоже не точно)
Разнообразные операции миграции, перепрезентации и так далее.
Допустим, у вас есть старое СХД (как у коллег), и ему скоро капууут. Новых дисков нет, поддержки нет, умрет контроллер - вообще беда. Есть два пути миграции
- средствами системы виртуализации делаем Live (или dead) migration.
Все хорошо, данные переедут рано или поздно, но это все равно снапшоты и последующая консолидация.
Можно сделать иначе, можно скомандовать новому хранилищу "хватай и тащи".
В результате нужные данные переедут в фоновом режиме, и затем старый LUN будет показан как "как бы вот он тут всегда и был".
При этом можно сделать так, чтобы старое СХД тоже не пропадало, и хранить данные частично на нем, чего добру и терабайтам пропадать.
Работает не для всех и не всегда, не для всех пар массивов и много чего еще "не".
Кеширование чтения на SSD.
У контроллеров на СХД есть свой кеш, он быстрый и полезный, однако не очень большой - десятки, может сотни гигабайт. Иногда же модель нагрузки такова, что нужно на большом СХД отдать кому-то много-много кеша на чтение. Есть такая возможность, отдаем SSD диск под кеш и радуемся. В сочетании с быстрым процессором на отдельном тонком (1U) сервере, или даже отдельной выделенном специальном считательном лезвии с быстрыми (по МГц) процессорами типа Intel Xeon Scalable https://habr.com/company/intel/blog/370791/
например
Intel® Xeon® Platinum 8156 Processor (3.6 / 3.7 Ггц, 105 W TDP) или Intel® Xeon® Gold 5122 Processor, те же 105 ватт.
Если же денег много, то можно еще и в лезвие поставить 2 SSD или 4 m2, собрать там raid 1/5/6 (если много смелости, то можно и 0), и будет убервундер 1с-лезвие, только бы памяти хватило (впрочем, слотов в обычном лезвии уже 16-24, а в полноразмерном и побольше, что позволяет набить в одно лезвие по паре терабайт).
Запуск виртуальных машин прямо на СХД.
Функция слегка странная, но в некоторых сценариях (то же видеонаблюдение) может и полезная.
Управляющая часть СХД - обычный x86 сервер, памяти и процессоров там много, так что почему бы не запустить какой-то простой сервис "прямо там".
Прочие функции.
Это разнообразные репликации, синхронные, асинхронные, метрокластера и так далее.
С ними все уже неплохо даже у средних СХД, но те, у кого два разнесенных датацентра, это и так знают в разы лучше меня.
Хотя, если у вас есть желание сделать тайную комнату (василиск - опционально) на случай прихода незванных гостей, поставить туда вторую СХД (попроще) и хранить там копию данных - то эта возможность есть.
Стирание
Иногда надо сделать так, чтобы данные были полностью уничтожены, однако диски при этом жалко.
В массивах, кроме шифрования (разного), есть и функция "стереть совсем". Функция конечно имеет ограниченную применяемость, применима не ко всем типов дисков и LUN, и, конечно, уступает такой полезной функции как "расплавить в домне или в современной дуговой печи / системе ковш-печь", но есть.
Обратная сторона функции: если у вас вдруг есть такой массив, нет оффлайн резервного копирования (по классике, 3-2-1, 3 копии, на двух типах носителей, 1 копия вне основной площадки) и у злых хацкеров (или вдруг заболевшего на всю голову админа) есть доступ - есть риск потерять все и сразу.
6. Куда это все развивается.
СХД сейчас развиваются в двух направлениях - это гиперконвергентные програмно-аппаратные комплексы (ПАК), и all-flash массивы. SSD диски подешевели в последние 5 лет в разы, если не десятки раз (на гигабайт), увеличили скорость, живучесть, варианты подключения. Как итог - дисков 15к уже почти нет (купить конечно еще можно), диски 10к уже на подходе, диски 7200 поживут еще.
Чипы (ASIC) и обработка в них тоже не стоят на месте.
Вывод - чтобы на новом месте не стоять с удивленным видом, матчасть стоит изучить уже сейчас, хотя бы поверхностно. Я к примеру "прямо сейчас" качаю свежий Nutanix CE, и собираюсь в магазин за парочкой SSD, просто чтобы дома посмотреть.
Цены на диски, или "почему SSD вытеснили 15к"
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, профиль нагрузки (дневной, ночной, во время резервного копирования).
На следующем этапе у бизнеса может возникнуть необходимость оценки в долларах таких вещей как RTO/RPO - сколько вы можете потерять данных, точнее на сколько денег вы можете потерять данных, на сколько вы можете остановить какой-то сервер, и так далее.
Если бизнесу это все еще не интересно в относительно точных цифрах, если оценка массива идет как "ну мы файл скопировали слева-направо, 100 Мб показало" - значит не интересно, что же тут поделать.
Вернее, что поделать как раз известно - прочитать и сделать что говорят по ссылкам в пп.8, может быть сдать экзамен и сменить работу на более денежную.
Пример RPO/RTO из жизни мелкого бизнеса: бухгалтеру было неудобно нажимать значок "RDP" и 1С переехала с сервера (SSD raid 10, hdd raid 1 для резервных копий) на локальный компьютер, тоже с SSD.
Вчера понесли SSD на восстановление, последняя резервная копия - 2 недели назад. Сдача отчетов через неделю. Цена вопроса - порядка 30 тысяч рублей, если повезет. Если не повезет, то рассказывать "у нас кошка сьела домашнюю работу", будут уже налоговой.
8. Ссылкота и что еще поискать
Главная книга" Nutanix http://nutanix.ru/ - очень полезная обзорная (и потом уже не только обзорная) книга "как это работает".
Highload 2016. Что уже умеют промышленные СХД.
http://blog.vadmin.ru/2016/11/highload-2016.html
Brocade: FC 101-WBT Introduction to Fibre Channel Concepts
Системы хранения данных Huawei Oceanstor V3
http://dendubinin.blogspot.com/2015/01/huawei-oceanstor-v3.html
Системы хранения данных Huawei Oceanstor V3 (часть 2)
http://dendubinin.blogspot.com/2015/01/huawei-oceanstor-v3-2.html
Системы хранения данных Huawei Oceanstor V3 (часть 3)
http://dendubinin.blogspot.com/2015/03/huawei-oceanstor-v3-4.html
Системы хранения данных Huawei Oceanstor V3 (часть 4)
http://dendubinin.blogspot.com/2015/03/huawei-oceanstor-v3-4.html
Huawei Storage Simulator
На удивление удобная штука. Это мелкий веб-сервер (сотни мегабайт), который позволяет у вас сделать виртуальную СХД. Подцепить ее конечно никуда нельзя, а вот понажимать всякие кнопочки, создать-снести дисковый домен, LUN и все что угодно, изучить логи и отдельно изучить командную строку - вполне можно.
Ссылки
http://support.huawei.com/enterprisetool/en/tool/Storage%20Simulator-TL1000000114
там брать файлы вида "Demo_for_".
Huawei Hands-on LAB - например
Huawei Dorado 5000 V3 Storage Active-Active Solution(Carrier/Enterprise)
https://support-hol.huawei.com/course/427
H6LH3AAE Managing HPE 3PAR StoreServ Hands On Lab
Это курс от HPE, за который хотят 23.400 рублей без НДС (а сами между тем НДС потом приписывают, что вызывает опрежеденные проблемы при проведении, и особенно при возврате).
HPE 3PAR StoreServ Simulator
https://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
https://www.ibm.com/developerworks/community/blogs/storagevirtualization/entry/vdisks_mdisks_extents_and_grains_scale_out_for_sure?lang=en
Пару дней назад позвонили мне коллеги с вопросом - старая дисковая полка совсем умирает ( у них старый еще 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.
Проблемы у такого самосбора есть во всем, начиная от скорости работы самого массива, заканчивая мониторингом, скоростью перестроения и различными аппаратно-программными фокусами.
Вообще, самое на мой взгляд больное место современных простых массивов - это скорость перестроения 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. Отдельно надо отметить решение "как бы непойми что" - это например вот такое
https://habr.com/company/tssolution/blog/425309/
Ни слова о том, что за ноды, что за контроллеры, что с снапшотами и бекапами, что там за "ну у нас не x86 в базе", и две полные потери данных в комментариях.
1.2. То же самое, но с завода и с обновлениями от производителя.
Это младшие QNap, Synology, кто там еще.
В таких СХД уже два блока питания, два контроллера SAS уровнем подороже, две сетевые карты 10G, или даже может быть FC 8/16, и все что сверху определено програмно - хотите iSCSI, хотите SMB (а если вы смелый, то даже и SMB 1.0), хотите NFS, можно FTP. Хотите - даже можно тонкие диски сделать. На контроллере даже кеш с батарейкой имеется!
Система хорошая, рабочая - но проблемы те же. И да, при обновлении будет перерыв в работе минут на 30 (если ОС) или на пару часов (если еще и FW контроллеров), и часто откатиться нельзя.
Сверху добавлены глюки как "от производителя", так и от того, что под капотом у такой СХД, какой контроллер и ОС.
1.3. Младшие всамделишные СХД. Уже с перламутровыми пуговицами.
Из известных это линейка HPE MSA - 2052, 2050, 2042, 2040, 1050, 1040, P2000 G3.
Dell конечно, да и Lenovo, старые Huawei
К примеру, сейчас старое (4-е) поколение линейки HPE MSA заканчивает жизненный цикл, как скромно пишут на сайте HPE - покупайте 1040 -> 1050, 2040 -> 2050, 2042 -> 2052.
Notice: HPE MSA 1040, 2040, 2042 SAN Storage - End Of Life Announcement
Release Date: 2017-12-11
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00038415en_us&docLocale=en_US
На этом уровне появляются такие функции, как апгрейд прошивки контроллера без перерыва сервиса, возможность замены контроллера на следующее поколение, само собой "горячая замена всего" - дисков, контроллеров, блоков питания. Появляются снапшоты на уровне СХД, тиринг (tiering), и удаленная репликация. Почитать не по русски можно скажем тут -
HPE MSA 2050 SAN Storage - Overview
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00017538en_us#N10087
или тут HPE MSA 1050/2050/2052 Best Practices https://h20195.www2.hpe.com/v2/getpdf.aspx/A00015961ENW.pdf
или тут в переводе https://habr.com/company/hpe/blog/426063/
Проблемы с перестроением Raid здесь все те же, и добавляются новые - с тем же тирингом.
Что такое тиринг я надеюсь все знают. Если не знают, то это объединение в одну группу хранения 2-3 типов разных дисков и типов Raid, например собираем в одну группу SSD в Raid 10, и SATA 7200 в Raid 6 / 60. После чего у нас СХД смотрит, к каким данным чаще обращались (горячие данные), и оставляет их на SSD, а более "холодные" отправляет на уровень ниже. В результате горячие данные лежат на SSD, совсем холодные на дешевых SATA 7200, а "ну так сяк" - как повезет.
Новые, свежие проблемы и боли начинаются примерно здесь, причем проблемы не с СХД. Простой пример - СХД куплено "задорого", а потом к ней запускают горе-специалистов из(от) того же Гилева, и они начинают в среде виртуализации гонять 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
Пока правда денег нет, но запрос цен на Dell/Lenovo/Huawei/HPE пожалуй сделаю.
2. Гиперконвергентные системы хранения.
Это совсем не младший сегмент, особенно Nutanix, однако, учитывая повсеместную горячую любовь к импортозамещению "по трофейному", и наличие Nutanix CE (а у некоторых даже и в продуктиве), то придется разместить тут.
Проще говоря, гиперконвергентно - это сервер набивается дисками и SSD, и рабочие данные лежат локально на тех же серверах, где и работают виртуальные машины (а копия - где-то еще).
Из широко известных систем это Nutanix (целиком, как програмно-аппаратный комплекс, хотя есть и CE "на посмотреть"), MS Storage space direct (S2D), VMWare VSAN. С последним все очень весело, система называется "ни дня без патчей", "мы опять страдаем", или, как c последним обновлением 6.7u1 - "мы сломали вам бекап, МВУ ХО ХО".
Не то чтобы у остальных этого не было, проблемы есть у всех, просто я чаще сталкиваюсь именно с VMWare.
В целом у этих систем все неплохо. И MS активно продается (причем даже в формате Azure stack - уже две штуки в РФ), и Nutanix растет и по продажам, и по капитализации, и выигрыш в скорости работы в некоторых сценариях у Nutanix порядочный, реально "в разы", вплоть до роста скорости работы некоторых сервисов по обсчету фотографий с 5 часов до часа (если не быстрее). Даже дедупликация с компрессией имеется.
Судя по финансовым показателям, у VMWare в целом пока тоже все неплохо.
3. Системы на базе Ceph, Gluster и так далее.
Можно что-то подобное собрать и на open source компонентах, особенно если вы смелый, и (или) у вас есть штат разработчиков, как в Кроке. Или данные не жалко. Конечно, такого как в Cloud Mouse больше не будет, что вы что вы. Или может просто фарту масти.
примеры раз https://habr.com/company/semrush/blog/353854/
примеры два https://habr.com/company/croccloudteam/blog/422905/
примеры три https://habr.com/company/croccloudteam/blog/417475/
Проблема - а как это все бекапить? И сколько будет перестраиваться при отказе одного диска или одной машины? Как настраивать и кто будет поддерживать? А если ваш администратор попадет под трамвай или просто уволится, то кто и почем возьмется за поддержку?
4. Современные СХД среднего ценового сегмента.
На хабре, кроме недостатка кнопки "вставить таблицу" и смешения (после слияния с GT) в одну кучу философии, политики, школьной космонавтики и осеннего обострения, имеется еще и почти полное отсутствие присутствия свежих статей про то, как работает современная СХД. Жбанков и Шапошников не пишут, поиск работает так же как таблицы - про 3par с 2015 года почти ни слова.
Быстренько нашлось три статьи про Huawei OceanStor
Импортозамещение Часть 2. Huawei OceanStor Family https://habr.com/post/254593/
три строки вот тут https://habr.com/company/lanit/blog/335242/
и тестирование All-flash OceanStor Dorado V3 https://habr.com/company/croc/blog/350152/
и есть парочка обзоров 2012-2015 года по 3par
пример https://habr.com/company/muk/blog/263469/
В большом интернете материалов на русском чуть больше, например тот же Oceanstor рассмотрен тут
http://dendubinin.blogspot.com/2015/01/huawei-oceanstor-v3-2.html
(кстати, в целом полезный бложек, набит ссылкотой по Huawei).
Итак, что нам предлагает современный массив уровня HPE 3par / Huawei / IBM-Lenovo.
В первую очередь, это новый подход к разбиению дисков. Это 3Par RAID, Huawei Raid 2.0 и у Lenovo-IBM тоже как-то называется (Storwize Distributed RAID (DRAID) это называется). Зачатки этого по слухам были еще в HP Enterprise Virtual Array (EVA), в 3Par пришло к логичному и более-менее понятному состоянию.
Как это работает. Вообще есть видео, хотя и на английском, но все понятно. https://youtu.be/LMe1CTL5rDY
Сначала мы выделяем дисковый домен. Просто группа дисков и не более.
Каждый отдельный диск разбивается на логические блоки по 64/256/1Гб, называемые у кого как. У HPE это chunklets, у Huawei chunk, у IBM - extent, но это не точно.
Потом уже из этих chunklets\chunk собираем блок, блок в группу, жучка за внучку, и в итоге получаем тонкий или толстый логический диск плюс зарезервированное пространство.
Какие плюсы от такого подхода к разбиению.
Плюсы достаточно простые.
В первую очередь, это гораздо более быстрое перестроение при сбое одного диска.
Если при сбое диска в Raid6 нам надо было прочитать все данные, посчитать математику и записать все данные на один диск, то узким местом становился сам результирующий диск.
Здесь же запись будет идти на все диски сразу. Тут конечно надо бы рассмотреть такой функционал, как запись полными страйпами, но этим сейчас сложно кого-то удивить.
В результате перестроение идет в разы быстрее.
ВНИМАНИЕ! Бекапы делать все равно надо! Raid - не бекап, и не защитит от некорректного изменения данных никак.
В вторую, это возможность делать всякое удобное в формате "тонких дисков". В принципе, это умеет делать и Microsoft, и Vmware, но оба с своими интересными особенностями в плане скорости. Тут, за счет кешей и предварительного выделения места "про запас", проблем чуть меньше.
Дедупликация и сжатие.
Та же дедупликация уже давно есть на NTFS, и недавно появилась на ReFS, но работает не всегда понятным мне образом.
На СХД есть возможность делать дедупликацию и сжатие на лету. Если у вас данные "похожие, а то и такие же", например LUN выделен строго под диски с операционными системами, то дедупликация высвободит 2\3 места (если не больше). Сжатие может быть добавит еще немного. Или много. Или, если у вас пожатое видео, вообще ничего не добавит.
Вышеупомянутый тиринг - когда раз в сутки, на ваш выбор, или холодные данные уходят на дешевые медленные диски, или вдруг внезапно ставшие горячими данные уходят на SSD.
Функция полезная, если применять с умом.
Снапшоты на уровне СХД.
Недооцениваемая многими полезная вещь.
Как бекапится виртуальная машина целиком "обычно" - делается снапшот, затем снапшот презентуется системе резервного копирования (СРК), после записи диска - система долго и нудно делает консолидацию.
При этом надо помнить, что неплохо бы внутри копируемой виртуальной машины иметь агент (сервис) системы резервного копирования, который скомандует прочим сервисам сбросить все кеши на диск и вообще постоять (это Volume Shadow Copy Service, VSS в Windows), для того чтобы, хотя формально та же база данных и лог транзакций (или база Exchange и логи к ней) были в "скорее всего неконсистентном виде" (статус dirty для того же exchange), но по факту в памяти ничего не осталось, и можно было быстро проверить журналы транзакций и дописать из них все, что нужно.
Снапшот на уровне СХД не отменяет необходимость иметь агента в системе, или (как кажется у Veeam) скопировать мелкое приложение и запустить его в момент запуска, но позволяет сократить время существования снапшота в среде виртуализации.
Как это работает.
Сначала агент делает командует приложению Halt!
Затем система резервного копирования делает снапшот виртуальной машины.
Затем система резервного копирования делает снапшот LUN от СХД (если умеет, конечно, и СХД поддерживает эту функцию. Veeam + 3par поддерживают эту функцию уже давно, Veeam + Huawei - с лета 2018
Пруф https://www.veeam.com/blog/intelligent-data-management-huawei-oceanstor.html
Аналогично с IBM, точнее IBM Storwize. С Nimble тоже интеграция была.
Читайте сайт Veeam, у них отличная русская поддержка.
Когда снапшот сделан уже на СХД, система командует Weggetreten! и запускает удаление снапшота. В результате у нас есть снапшот на СХД (средствами СХД и более-менее целый) и быстро удаленный снапшот в среде виртуализации. В результате нет длительного ожидания "пока у нас СРК вытащит снапшот" и потом "когда же у нас пройдет консолидация", а виртуалка работает дальше.
Конечно, данные затем будут забираться уже с СХД, и тут сильного выигрыша в скорости не будет, но это уже будет гораздо быстрее в целом, за счет работы и оптимизированных кешей на чтение, и того что система будет писать свой снапшот туда, где ей удобней и быстрее, а это может оказаться и SSD (но это не точно), да и консолидация будет быстрее в пару раз (это тоже не точно)
Разнообразные операции миграции, перепрезентации и так далее.
Допустим, у вас есть старое СХД (как у коллег), и ему скоро капууут. Новых дисков нет, поддержки нет, умрет контроллер - вообще беда. Есть два пути миграции
- средствами системы виртуализации делаем Live (или dead) migration.
Все хорошо, данные переедут рано или поздно, но это все равно снапшоты и последующая консолидация.
Можно сделать иначе, можно скомандовать новому хранилищу "хватай и тащи".
В результате нужные данные переедут в фоновом режиме, и затем старый LUN будет показан как "как бы вот он тут всегда и был".
При этом можно сделать так, чтобы старое СХД тоже не пропадало, и хранить данные частично на нем, чего добру и терабайтам пропадать.
Работает не для всех и не всегда, не для всех пар массивов и много чего еще "не".
Кеширование чтения на SSD.
У контроллеров на СХД есть свой кеш, он быстрый и полезный, однако не очень большой - десятки, может сотни гигабайт. Иногда же модель нагрузки такова, что нужно на большом СХД отдать кому-то много-много кеша на чтение. Есть такая возможность, отдаем SSD диск под кеш и радуемся. В сочетании с быстрым процессором на отдельном тонком (1U) сервере, или даже отдельной выделенном специальном считательном лезвии с быстрыми (по МГц) процессорами типа Intel Xeon Scalable https://habr.com/company/intel/blog/370791/
например
Intel® Xeon® Platinum 8156 Processor (3.6 / 3.7 Ггц, 105 W TDP) или Intel® Xeon® Gold 5122 Processor, те же 105 ватт.
Если же денег много, то можно еще и в лезвие поставить 2 SSD или 4 m2, собрать там raid 1/5/6 (если много смелости, то можно и 0), и будет убервундер 1с-лезвие, только бы памяти хватило (впрочем, слотов в обычном лезвии уже 16-24, а в полноразмерном и побольше, что позволяет набить в одно лезвие по паре терабайт).
Запуск виртуальных машин прямо на СХД.
Функция слегка странная, но в некоторых сценариях (то же видеонаблюдение) может и полезная.
Управляющая часть СХД - обычный x86 сервер, памяти и процессоров там много, так что почему бы не запустить какой-то простой сервис "прямо там".
Прочие функции.
Это разнообразные репликации, синхронные, асинхронные, метрокластера и так далее.
С ними все уже неплохо даже у средних СХД, но те, у кого два разнесенных датацентра, это и так знают в разы лучше меня.
Хотя, если у вас есть желание сделать тайную комнату (василиск - опционально) на случай прихода незванных гостей, поставить туда вторую СХД (попроще) и хранить там копию данных - то эта возможность есть.
Стирание
Иногда надо сделать так, чтобы данные были полностью уничтожены, однако диски при этом жалко.
В массивах, кроме шифрования (разного), есть и функция "стереть совсем". Функция конечно имеет ограниченную применяемость, применима не ко всем типов дисков и LUN, и, конечно, уступает такой полезной функции как "расплавить в домне или в современной дуговой печи / системе ковш-печь", но есть.
Обратная сторона функции: если у вас вдруг есть такой массив, нет оффлайн резервного копирования (по классике, 3-2-1, 3 копии, на двух типах носителей, 1 копия вне основной площадки) и у злых хацкеров (или вдруг заболевшего на всю голову админа) есть доступ - есть риск потерять все и сразу.
6. Куда это все развивается.
СХД сейчас развиваются в двух направлениях - это гиперконвергентные програмно-аппаратные комплексы (ПАК), и all-flash массивы. SSD диски подешевели в последние 5 лет в разы, если не десятки раз (на гигабайт), увеличили скорость, живучесть, варианты подключения. Как итог - дисков 15к уже почти нет (купить конечно еще можно), диски 10к уже на подходе, диски 7200 поживут еще.
Чипы (ASIC) и обработка в них тоже не стоят на месте.
Вывод - чтобы на новом месте не стоять с удивленным видом, матчасть стоит изучить уже сейчас, хотя бы поверхностно. Я к примеру "прямо сейчас" качаю свежий Nutanix CE, и собираюсь в магазин за парочкой SSD, просто чтобы дома посмотреть.
Цены на диски, или "почему SSD вытеснили 15к"
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, профиль нагрузки (дневной, ночной, во время резервного копирования).
На следующем этапе у бизнеса может возникнуть необходимость оценки в долларах таких вещей как RTO/RPO - сколько вы можете потерять данных, точнее на сколько денег вы можете потерять данных, на сколько вы можете остановить какой-то сервер, и так далее.
Если бизнесу это все еще не интересно в относительно точных цифрах, если оценка массива идет как "ну мы файл скопировали слева-направо, 100 Мб показало" - значит не интересно, что же тут поделать.
Вернее, что поделать как раз известно - прочитать и сделать что говорят по ссылкам в пп.8, может быть сдать экзамен и сменить работу на более денежную.
Пример RPO/RTO из жизни мелкого бизнеса: бухгалтеру было неудобно нажимать значок "RDP" и 1С переехала с сервера (SSD raid 10, hdd raid 1 для резервных копий) на локальный компьютер, тоже с SSD.
Вчера понесли SSD на восстановление, последняя резервная копия - 2 недели назад. Сдача отчетов через неделю. Цена вопроса - порядка 30 тысяч рублей, если повезет. Если не повезет, то рассказывать "у нас кошка сьела домашнюю работу", будут уже налоговой.
8. Ссылкота и что еще поискать
Главная книга" Nutanix http://nutanix.ru/ - очень полезная обзорная (и потом уже не только обзорная) книга "как это работает".
Highload 2016. Что уже умеют промышленные СХД.
http://blog.vadmin.ru/2016/11/highload-2016.html
Brocade: FC 101-WBT Introduction to Fibre Channel Concepts
Системы хранения данных Huawei Oceanstor V3
http://dendubinin.blogspot.com/2015/01/huawei-oceanstor-v3.html
Системы хранения данных Huawei Oceanstor V3 (часть 2)
http://dendubinin.blogspot.com/2015/01/huawei-oceanstor-v3-2.html
Системы хранения данных Huawei Oceanstor V3 (часть 3)
http://dendubinin.blogspot.com/2015/03/huawei-oceanstor-v3-4.html
Системы хранения данных Huawei Oceanstor V3 (часть 4)
http://dendubinin.blogspot.com/2015/03/huawei-oceanstor-v3-4.html
Huawei Storage Simulator
На удивление удобная штука. Это мелкий веб-сервер (сотни мегабайт), который позволяет у вас сделать виртуальную СХД. Подцепить ее конечно никуда нельзя, а вот понажимать всякие кнопочки, создать-снести дисковый домен, LUN и все что угодно, изучить логи и отдельно изучить командную строку - вполне можно.
Ссылки
http://support.huawei.com/enterprisetool/en/tool/Storage%20Simulator-TL1000000114
там брать файлы вида "Demo_for_".
Huawei Hands-on LAB - например
Huawei Dorado 5000 V3 Storage Active-Active Solution(Carrier/Enterprise)
https://support-hol.huawei.com/course/427
H6LH3AAE Managing HPE 3PAR StoreServ Hands On Lab
Это курс от HPE, за который хотят 23.400 рублей без НДС (а сами между тем НДС потом приписывают, что вызывает опрежеденные проблемы при проведении, и особенно при возврате).
HPE 3PAR StoreServ Simulator
https://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
https://www.ibm.com/developerworks/community/blogs/storagevirtualization/entry/vdisks_mdisks_extents_and_grains_scale_out_for_sure?lang=en
no subject
Date: 2018-10-20 12:26 pm (UTC)младшие кунапы и синолоджи - это говно на х86 и арме, с зфс и прочей лабудой внутре (плюс неонка).
человек купивший в 2018 году р2000 - идиот
no subject
Date: 2018-10-20 12:34 pm (UTC)https://blog.mwpreston.net/2015/11/07/learning-3par-part-1-chunklets-logical-disk-cpgs-and-virtual-volumes/
и может пересмотреть видео по 3пар
no subject
Date: 2018-10-20 12:52 pm (UTC)Внизу у нас виртуальный Raid 50. 4 группы по 5 дисков
Пусть у нас есть такого же объема Raid 5.
В первом случае у нас вылетает 2 диска в РАЗНЫХ группах, и ребилд идет в ДВА потока. по N iops на каждый диск, всего поток N*2
В втором случае у нас поток будет только 1*N, и скорость в два раза ниже.
В случае если у нас 10 групп по 5 дисков, и вылетело по диску в каждой группе - то пойдет 10 ребилдов, на 10 дисков, с N*10 скоростью.
Видео добавить про триппер и чанклеты.
https://www.youtube.com/watch?v=8E5fhnYSrok
no subject
Date: 2018-10-20 01:03 pm (UTC)https://www.youtube.com/watch?v=MaTU2xc23NE
Да, после того как умерший диск будет вытащен, и новый вставлен и инициализирован, система медленно и тихо, не мешая (ну как не мешая. Если у вас постоянно диски нагружено под 100% потоком ввода-вывода, то с проблемами) потащит данные на этот диск.
но ПОТОМ.
А сейчас, пока диск умер, данные будут размазываться по зарезервированному свободному месту в много потоков
no subject
Date: 2018-10-20 01:03 pm (UTC)— Мам, а тяжело быть начальником отдела? — Нет, сынок, это то же самое, что сидеть в бочке с говном, вокруг которой катаются инженеры на велосипедах и орут, что они в огне и горят в аду. Они в огне, а ты в говне и все вокруг тыкают в тебя пальцем и кричат — вот она — тварь, из-за которой всё плохо...
— Мам, а тяжело быть техническим директором? — Да, сынок! Очень тяжело. Нужно постоянно подливать в бочку с начальником отдела говно, чтобы было всегда по горло. Поджигать велосипеды инженерам. Да, и следить, чтобы они никогда не погасали, чтоб те крутили педали как черти — а ты весь такой всегда чистый должен быть ... с ежедневником, куда записываешь планы ремонта бочки и закупки велосипедов.
no subject
Date: 2018-10-20 01:24 pm (UTC)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.