Allocation group — это внутренняя абстракция T-RAID и управляется системой автоматически. Такой подход был изначально заложен в дизайн, чтобы избавить пользователей от необходимости вручную управлять группировкой дисков.
Администратор, в рамках своих сервисных процедур, может получить информацию о составе alloc groups, их емкости и других метриках. Однако, например, при добавлении нового диска, система самостоятельно определяет, в какую allocation group его включить, при этом приоритет отдается неполным группам, если в одной из них произошла потеря диска.
как собирается allocation group? это диски одного, условно, "качества" или сущ ещё какие-то критерии ее создания? вообще, можно потерять всю такую группу (вопросы навеяны HPE 3par)
allocation group собирается как k+m дисков пула, соответственно: alloc_group_cnt = disk_cnt / (k+m)
Что касается "качества" дисков, если я правильно понял вопрос, то да — диски внутри пула должны быть одного класса. Например, нельзя смешивать rotational и non-rotational диски в одном пуле.
Если требуется дополнительная информация, уточните, пожалуйста — я буду рад пояснить детали.
и не могу не подлить масла в огонь, но почему у симметричного кластера ноды определены как primary-secondary?) что в таком случае, несимметричный кластер?)
В симметричном кластере обе ноды работают одновременно и обрабатывают I/O-запросы параллельно. Если одна выходит из строя, вторая полностью берет на себя нагрузку без изменения логики доступа.
В несимметричном кластере - активно обрабатывает запросы только одна нода, а вторая включается только при отказе первой.
Разделение на primary-secondary/master-slave нужно для поддержания блокировок и сброс индексов на диски (этим занимается master).
Я правильно понял, что единица аллокации у вас 16МБ? Т.е. если записали 4КБ в том, то по факту заняли 16МБ физически?
Верно, только 16МБ - единица аллокации одного блока, а таких блоков нам нужно аллоцировать количеством k+m (по схеме защиты). То есть, для поддержания записи данных размером min(sz, k * 16МБ), будет аллоцировано (k+m) * 16МБ (k для данных пользователя, m для parity T-RAID).
Не очень понял почему CRC сохраняете на парные блоки? Почему просто отдельно на блок не храните?
Смысл в дополнительной защите от коррапта на диске, когда покорраптилась и данные, и контрольная сумма, но она сошлась. С помощью соседа мы сможем узнать, что на самом деле проблема присутствует.
В DIF отводится 16бит под CRC. Вам хватает CRC16 на практике или вы что-то другое используете? Слишком высокая вероятность коллизии у нее.
Вероятность коллизии действительно высокая, поэтому мы используем комбинированный подход: 16 бит crc для проверки контрольных сумм во время I/O + фоновый процесс scrubber для более строгой гарантии целостности данных.
Как я понял страйп вы пишете inplace, т.к. не используете RedirectOnWrite, CopyOnWrite. Как вы гарантируете атомарность записи страйпа(проблема Raid Write Hole)?
Для упрощения предположим, что нам прилетел запрос в пределах страйпа. Мы берем распределенную блокировку на этот страйп, тем самым гарантируя целостность данных между несколькими I/O.
Если ошибка записи более чем на m стрипов, мы возвращаем I/O ошибку на эту запись, это будет означать неконсистентность данных в этих блоках (ни старых, ни новых данных там больше нет), recovery пометит данные блоки как потерянные и аллоцирует на их место свежие.
Если ошибка менее чем на m стрипов, мы подтверждаем I/O, далее recovery переаллоцирует сломанные блоки.
Так же здесь присутствует интересный сценарий, связанный с отказом оборудования (например, у СХД выключили питание): К СХД к каждой из нод локально подключены диски, которые питаются от батареи, туда мы записываем emergency информацию при множественных ошибках записи на диски во время выключения питания, с помощью которой, при последующем включении системы, можно будет восстановиться
TRAID у вас реализован в linux kernel?
Да, T-RAID - Linux Kernel module, сейчас используем ядро 6.12
Allocation group — это внутренняя абстракция T-RAID и управляется системой автоматически. Такой подход был изначально заложен в дизайн, чтобы избавить пользователей от необходимости вручную управлять группировкой дисков.
Администратор, в рамках своих сервисных процедур, может получить информацию о составе alloc groups, их емкости и других метриках. Однако, например, при добавлении нового диска, система самостоятельно определяет, в какую allocation group его включить, при этом приоритет отдается неполным группам, если в одной из них произошла потеря диска.
Спасибо!
Да, это связано с архитектурой TATLIN.UNIFIED.
allocation group собирается как k+m дисков пула, соответственно:
alloc_group_cnt = disk_cnt / (k+m)
Что касается "качества" дисков, если я правильно понял вопрос, то да — диски внутри пула должны быть одного класса. Например, нельзя смешивать rotational и non-rotational диски в одном пуле.
Если требуется дополнительная информация, уточните, пожалуйста — я буду рад пояснить детали.
В симметричном кластере обе ноды работают одновременно и обрабатывают I/O-запросы параллельно. Если одна выходит из строя, вторая полностью берет на себя нагрузку без изменения логики доступа.
В несимметричном кластере - активно обрабатывает запросы только одна нода, а вторая включается только при отказе первой.
Разделение на primary-secondary/master-slave нужно для поддержания блокировок и сброс индексов на диски (этим занимается master).
Спасибо за фидбек!
Верно, только 16МБ - единица аллокации одного блока, а таких блоков нам нужно аллоцировать количеством k+m (по схеме защиты). То есть, для поддержания записи данных размером min(sz, k * 16МБ), будет аллоцировано (k+m) * 16МБ (k для данных пользователя, m для parity T-RAID).
Смысл в дополнительной защите от коррапта на диске, когда покорраптилась и данные, и контрольная сумма, но она сошлась. С помощью соседа мы сможем узнать, что на самом деле проблема присутствует.
Вероятность коллизии действительно высокая, поэтому мы используем комбинированный подход: 16 бит crc для проверки контрольных сумм во время I/O + фоновый процесс scrubber для более строгой гарантии целостности данных.
Для упрощения предположим, что нам прилетел запрос в пределах страйпа.
Мы берем распределенную блокировку на этот страйп, тем самым гарантируя целостность данных между несколькими I/O.
Если ошибка записи более чем на m стрипов, мы возвращаем I/O ошибку на эту запись, это будет означать неконсистентность данных в этих блоках (ни старых, ни новых данных там больше нет), recovery пометит данные блоки как потерянные и аллоцирует на их место свежие.
Если ошибка менее чем на m стрипов, мы подтверждаем I/O, далее recovery переаллоцирует сломанные блоки.
Так же здесь присутствует интересный сценарий, связанный с отказом оборудования (например, у СХД выключили питание):
К СХД к каждой из нод локально подключены диски, которые питаются от батареи, туда мы записываем emergency информацию при множественных ошибках записи на диски во время выключения питания, с помощью которой, при последующем включении системы, можно будет восстановиться
Да, T-RAID - Linux Kernel module, сейчас используем ядро 6.12