meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
blog:2022:09:16 [2022/09/17 08:57] – mchusblog:2022:09:16 [2022/09/22 07:07] (current) – mchus
Line 1: Line 1:
 +====== 2022-09-16 Почему нельзя занимать СХД "под завязку" ======
 +{{tag>storage}}
 +Производители большинства систем хранения данных не рекомендуют тратить всю ёмкость пула, рекомендуя оставлять определенный запас   в объеме от 30 до 10%. Можно ли пренебрегать этими рекомендациями и что случиться если им не следовать?
 +
 +Как вы знаете системы хранения данных грубо можно разделить на два вида:
 +  - Классические и гибридные СХД с вращающимися жесткими дисками
 +  - AFF ((All Flash)) - СХД только на твердотельных дисках
 +
 +Начнём с последних
 +
 +====== All Flash ======
 +
 +СХД AllFlash - эти системы работают практически как один большой SSD диск. Все уже наверное знают что современные твердотельные диски могут записать в одну ячейку памяти только несколько битов информации (2, 3, 4) другими словами если необходимо записать один бит все равно ячейка будет записана целиком. Контроллер диска считывает содержимое ячейки, добавляет к нему новый бит информации  и записывает обратно. Этот эффект называется Write Cliff, потому что график записи такого SSD диска представляет собой ровный холм, заканчивающийся обрывом.
 +
 +{{:blog:2022:09:16:20220916-185710.png}}
 +
 +Write cliff появляется тогда, когда свободные ячейки в которые можно писать без подготовки у диска закончились и ему срочно необходимо что-то предпринимать. Диск начинает уже не в фоне, а в приоритете дефрагментировать ячейки чтобы освободить новые блоки для записи. 
 +
 +Такая же проблема может коснуться и систем хранения данных. При активном изменении данных, то есть случайной записи, особенно когда система долго время работает на пределе производительности свободные блоки могут закончиться. И чем меньше свободного места в пуле - тем больше вероятность наступления этого события. 
 +
 +====== Массивы преимущественно на жестких дисках (и гибриды)  ======
 +
 +Массивы на HDD по сравнению с AFF системами настоящее произведение искусства. В эти системы заложено очень много логики чтобы снизить влияние таких нестабильных устройств как жесткие диски, всяческие алгоритмы оптимизации расположения блоков на пластине диска, хитрые механизмы перестроения много ко многим, файловые системы которые пишут всегда в чистое место чтобы не "патчить raid страйп", хитрые проприетарные RAID алгоритмы, RAID из блоков а не дисков, многоуровневые кэши, иерархическое хранение и многое другое. 
 +
 +{{:blog:2022:09:16:20220916-191645.png}}
 +
 +Эти продвинутые механизмы были призваны снизить время отклика системы и "выжать максимум" из жестких дисков, обладающих неплохой последовательной производительностью и просто ужасной, по сравнению с SSD скоростью позиционирования. 
 +
 +Для дисковой СХД netapp принято закладывать порядка 30% запаса ёмкости в виду того что скорость системы резко падает при необходимости модификации уже записанных блоков и теряется все преимущество файловой системы WAFL, пишущей всегда в пустое место. 
 +
 +Архитектурные особенности WAFL можно сравнить с файловыми системами и СХД работающими по принципу CoW ((Copy on write)), например ZFS, BTRFS. 
 +Данные в таких ФС не удаляются мгновенно и не перезаписываются, а при изменении просто меняется ссылка на блок данных диска. Такие системы обладают рядом преимуществ перед традиционными, но сильнее других страдают от нехватки свободного пространства.
 +
 +{{:blog:2022:09:16:20220916-205704.png}}
 +
 +
 +===== Виртуализация СХД ======
 +<WRAP center round info 60%>
 +Виртуализация СХД это процесс презентации дискового ресурса одного или нескольких массивов другой системе, не серверу, для объединения в один убер-пул. Именно виртуализатор - система которая собирает все массивы в один, презентует диски серверу. Именно на ней создаются логические тома и пулы.
 +
 +Пожалуйста не путайте виртуализацию СХД и виртуализацию вычислительных ресурсов (виртуальные машины).
 +</WRAP>
 +
 +При виртуализации дисковой емкости нет такого требования - оставлять запас на **виртуализуемых СХД** в размере 20%. Правило для всех виртуализаторов одинаковое - создать самую базовую сущность, в идеале RAID группу. Создать на группе том максимального размера (если речь о HDD) и презентовать его виртуализатору для дальнейшего использования.
 +
 +Во первых когда мы создаем один большой диск - емкость тратится, но занята она ничем. Даже если используется не "тонкое" а "толстое" выделение дисковой емкости. 
 +
 +Во вторых, именно на системе виртуализаторе нам необходимо позаботиться и заложить эти 10-20-30% ёмкости в пуле чтобы дочерние СХД жили спокойно. 
 +
 +В третьих виртуализатор многое меняет в характере поступающей нагрузки к системам, на которых он паразитирует. Он как бы выравнивает нагрузку, распределяет между несколькими СХД при наличии, пользуется своим кэшем: маленькие блоки делает больше, большие блоки делает меньше, буквально как коньяк, но для СХД. 
 +
 +В этом случае деградации производительности на массивах и вовсе может не произойти даже при фактическом заполнении ёмкости.