В TATLIN.BACKUP используется два разных пула дисков: первый для метаданных, второй для данных.
Полки хранят только данные.
Если рейд под данными развалился, то вся система теряет целостность (сторедж дедуплицирующий!) и это ситуация вообще говоря очень серьезная. Тут хотя бы что-то спасти, целостность снапшотов созданных во время отлета дисков будет наименьшей проблемой.
Если просто потеряно соединение с полкой с дисками которые хранят данные в момент создания снапшота, то снапшот будет просто корректно создан и когда соединение с полкой восстановится снапшот будет доступен. Состояние полки после восстановления соединения проверяется Health Check и стандартными средствами T-RAID.
Ну отъехать полка может или по обрыву кабеля/питания или если RAID отлетел (3 диска).
Если три диска умерло, то тут 50/50 может не повезти и отлетит целая группа что значит потерю целостности всей системы.
Если в одной группе умерло 2 или 1 диск и в другой 2 или 1 то мы просто продолжаем работать. RAID просто будет шуршать и восстанавливать данные.
Если произошел обрыв соединения с полкой, то создание снапшота (а у нас снапшот не дисков а файловой системы!) это в TATLIN.BACKUP вообще никак не затрагивает, потому что все операции тут проводятся на мета пуле, а он вообще находится в голове СХД.
Файловый доступ это NFS, SMB, T-BOOST. Благодаря снапшотам у зловреда не получится испортить данные через уязвимость файлового доступа - если утек токен, учетка, баг какой-то найден и так далее. Именно это вирусы эксплуатировать против снапшотов не смогут. Ну и такие уязвимости в целом как будто чаще возникают чем возможность прорутоваться на СХД.
Тем не менее вы правы, что у любой сложной системы, которая торчит портами наружу, могут быть уязвимости в сервисах (вот в четырех верхних), которые позволяют прорутоваться. В сущности опыт некоторых СРК это показывает. Да и не только СРК. В сущности уязвима любая система с веб мордой, потому что так или иначе веб морда раздается веб сервером. По сути СХД - это просто много дисков и контроллер. Если я прорутовался на контроллере, то я просто иду стирать/шифровать все диски. И все. Не будет ни снапшотов, ни LUN, ничего не будет.
От этого защиты могут быть такие: 1) системное исправление security issues (мы такое делаем) 2) увод сервисов с запуска под рутом, чтобы для взлома надо было еще использовать уязвимости ядра для повышения привилегий, что, как будто, уменьшает вероятность успешного взлома (мы такое делаем) 3) всякая изоляция - чтобы даже прорутовавшись с помощью уязвимости - дисковые пулы были не видны (это делаем для сервисов) 4) репликация на другую площадку (это будет - с помощью снапшотов, кстати) 5) отчуждение хранимого в сейф/отключение хранилища от сети/запрет входящих соединений, чтобы СХД сама ходила и забирала данные (тоже ходят про это идеи)
Мы действительно предоставляем через REST интерфейс возможности по созданию снапшотов и манипуляциям над ними. Снапшоты хранят данные в режиме READ ONLY. Данные не удалить. Следующая линия защиты - что есть снапшоты в состояниях Secure и Locked - которые нельзя просто взять удалить, даже с помощью взломанного сервера СРК. Secure снапшот для удаления надо сначала перевести в базовое состояние и только специальный пользователь TB может это сделать. Locked вообще только сервисный инженер может удалить. Кроме того, на снапшоты выставляются сроки хранения, чтобы не надо было их руками удалять.
В TB снапшоты это RO сущности поэтому "обычным" доступом их не повредить, как и бекапы в них хранящиеся. IO стек просто команды записи не пропустит. Чтобы повредить сами данные снапшотов или метаданные надо получить рутовый доступ к TB. Кстати действительно есть тенденция что зловреды сначала пытаются найти backup appliance и вывести его из строя любой ценой. Если это не удается - они даже не активируются - потому что ну а смысл - все равно прод будет восстановлен. Поэтому мы используем статический анализ, проверяем какие уязвимости есть и так далее, чиним security issues.
1) Если рассматривать метаданные то и COW и ROW меняют одну ссылку. Если смотреть под микроскопом - Latency будет зависеть от того как хранятся метаданные, как кеш устроен метаданных, есть ли NVRAM. Утверждать что перекидывание ссылки в 2 раза учеличивет latency нельзя. Точные цифры изменения latency нельзя сказать и про запись на диск. Строго говоря ROW и COW отличаются тем что COW делает две записи данных и это абсолютно точно увеличивает нагрузку на IO стек и дисковую подсистему. Насколько - на это влияет много разных параметров 2) Размер блока COW/ROW снапшота стоит выбирать кратным блоку диска/raid над ним. Нужно понимать что у вас является единицей обмена в IO стеке, чтобы не "цеплять" лишние блоки. Сам по себе RMW будет возникать в любом случае.
TBFS позволяет создавать много файловых систем и монтировать их на директории. Потом этими директориями можно пользоваться как ну.. Обычными директориями. Делать ls, создавать файлы, например. Затем да - можно эти директории раздать как SMB шару или NFS экспорт с помощью NFS и SMB серверов. Сервера частью TBFS не являются.
А вот T-BOOST работает по сетевому интерфейсу прямо из TBFS, и сетевой сервер T-BOOST встроен в TBFS.
Во время нарезки блок переменной длины болтается около 10 Кб, после сжатия он становится 4 Кб.
Делим 690 ТБ на 4 КБ получаем 172 500 000 000 блоков на машине. Это наши "празднующие".
Хеш 32 байта, значит "дней в году" 2^256.
Ну и там дальше это хозяйство подставляем в формулу честную и оцениваем сколько нулей будет или в аппроксимацию, которую можно посчитать математическим пакетом.
Честная формула чтобы получить вероятность что хотя бы у двоих празднующих день рождения совпал
Ну T-RAID он все таки не физический контроллер, это софтверное решение. Про него можно тут поподробнее почитать какие сервисы он предоставляет (там как минимум есть scrubber и recovery) https://habr.com/ru/companies/yadro/articles/885320/
У нас есть еще сервисы которые смотрят за его состоянием и управляют T-RAID. Это немного отдельная от TBFS и сложная история.
Сейчас главное, что мы не выдаем втихую некорректные данные. Если на дисках произошла невосстановимая беда, система ответит, что какие-то данные не читаются и зажжет алерт. И аналогичные PBBA тоже проверяют именно это. Если какие-то хеши на каком-то уровне не сошлись - все, пора сообщать пользователю. А восстановление, если возможно - с помощью парити средствами RAID.
Bit rot решаем с помощью RAID + DIF T10. У нас T-RAID из TATLIN.UNIFIED на борту, он позволяет это сделать.
До полностью своего RAID, заточенного на хранение блоков с хешами и красивыми валидациями через это, чтобы запускать пересчеты парити или данных - пока не доросли. Пока вот DIF в дополнение к подписям блоков там считается и сохраняется.
Допустим у меня есть информационная система и я сохранил ее резервную копию 1 января. До этого не было резервных копий. В этом случае резервная копия нарежется на блоки и все блоки будут сохранены, потому что TB их еще не видел.
Когда я пойду сохранять резервную копию той же информационной системы 7 января, TB вычленит изменившиеся регионы файлов и сохранит их на диск. Остальные регионы файла будут адресованы к уже сохраненным блокам. Ну тут в целом понятно что изменений между 1 и 7 января вряд ли много.
В TATLIN.BACKUP используется два разных пула дисков: первый для метаданных, второй для данных.
Полки хранят только данные.
Если рейд под данными развалился, то вся система теряет целостность (сторедж дедуплицирующий!) и это ситуация вообще говоря очень серьезная. Тут хотя бы что-то спасти, целостность снапшотов созданных во время отлета дисков будет наименьшей проблемой.
Если просто потеряно соединение с полкой с дисками которые хранят данные в момент создания снапшота, то снапшот будет просто корректно создан и когда соединение с полкой восстановится снапшот будет доступен. Состояние полки после восстановления соединения проверяется Health Check и стандартными средствами T-RAID.
Ну отъехать полка может или по обрыву кабеля/питания или если RAID отлетел (3 диска).
Если три диска умерло, то тут 50/50 может не повезти и отлетит целая группа что значит потерю целостности всей системы.
Если в одной группе умерло 2 или 1 диск и в другой 2 или 1 то мы просто продолжаем работать. RAID просто будет шуршать и восстанавливать данные.
Если произошел обрыв соединения с полкой, то создание снапшота (а у нас снапшот не дисков а файловой системы!) это в TATLIN.BACKUP вообще никак не затрагивает, потому что все операции тут проводятся на мета пуле, а он вообще находится в голове СХД.
Не совсем. Давайте разберем какие сетевые доступы на TB есть:
1) NFS сервер
2) SMB сервер
3) T-BOOST сервер
4) веб сервер
Файловый доступ это NFS, SMB, T-BOOST. Благодаря снапшотам у зловреда не получится испортить данные через уязвимость файлового доступа - если утек токен, учетка, баг какой-то найден и так далее. Именно это вирусы эксплуатировать против снапшотов не смогут. Ну и такие уязвимости в целом как будто чаще возникают чем возможность прорутоваться на СХД.
Тем не менее вы правы, что у любой сложной системы, которая торчит портами наружу, могут быть уязвимости в сервисах (вот в четырех верхних), которые позволяют прорутоваться. В сущности опыт некоторых СРК это показывает. Да и не только СРК. В сущности уязвима любая система с веб мордой, потому что так или иначе веб морда раздается веб сервером. По сути СХД - это просто много дисков и контроллер. Если я прорутовался на контроллере, то я просто иду стирать/шифровать все диски. И все. Не будет ни снапшотов, ни LUN, ничего не будет.
От этого защиты могут быть такие:
1) системное исправление security issues (мы такое делаем)
2) увод сервисов с запуска под рутом, чтобы для взлома надо было еще использовать уязвимости ядра для повышения привилегий, что, как будто, уменьшает вероятность успешного взлома (мы такое делаем)
3) всякая изоляция - чтобы даже прорутовавшись с помощью уязвимости - дисковые пулы были не видны (это делаем для сервисов)
4) репликация на другую площадку (это будет - с помощью снапшотов, кстати)
5) отчуждение хранимого в сейф/отключение хранилища от сети/запрет входящих соединений, чтобы СХД сама ходила и забирала данные (тоже ходят про это идеи)
Мы действительно предоставляем через REST интерфейс возможности по созданию снапшотов и манипуляциям над ними.
Снапшоты хранят данные в режиме READ ONLY. Данные не удалить.
Следующая линия защиты - что есть снапшоты в состояниях Secure и Locked - которые нельзя просто взять удалить, даже с помощью взломанного сервера СРК. Secure снапшот для удаления надо сначала перевести в базовое состояние и только специальный пользователь TB может это сделать. Locked вообще только сервисный инженер может удалить. Кроме того, на снапшоты выставляются сроки хранения, чтобы не надо было их руками удалять.
В TB снапшоты это RO сущности поэтому "обычным" доступом их не повредить, как и бекапы в них хранящиеся. IO стек просто команды записи не пропустит. Чтобы повредить сами данные снапшотов или метаданные надо получить рутовый доступ к TB.
Кстати действительно есть тенденция что зловреды сначала пытаются найти backup appliance и вывести его из строя любой ценой. Если это не удается - они даже не активируются - потому что ну а смысл - все равно прод будет восстановлен.
Поэтому мы используем статический анализ, проверяем какие уязвимости есть и так далее, чиним security issues.
1) Если рассматривать метаданные то и COW и ROW меняют одну ссылку. Если смотреть под микроскопом - Latency будет зависеть от того как хранятся метаданные, как кеш устроен метаданных, есть ли NVRAM. Утверждать что перекидывание ссылки в 2 раза учеличивет latency нельзя. Точные цифры изменения latency нельзя сказать и про запись на диск. Строго говоря ROW и COW отличаются тем что COW делает две записи данных и это абсолютно точно увеличивает нагрузку на IO стек и дисковую подсистему. Насколько - на это влияет много разных параметров
2) Размер блока COW/ROW снапшота стоит выбирать кратным блоку диска/raid над ним. Нужно понимать что у вас является единицей обмена в IO стеке, чтобы не "цеплять" лишние блоки. Сам по себе RMW будет возникать в любом случае.
TBFS позволяет создавать много файловых систем и монтировать их на директории. Потом этими директориями можно пользоваться как ну.. Обычными директориями. Делать ls, создавать файлы, например. Затем да - можно эти директории раздать как SMB шару или NFS экспорт с помощью NFS и SMB серверов. Сервера частью TBFS не являются.
А вот T-BOOST работает по сетевому интерфейсу прямо из TBFS, и сетевой сервер T-BOOST встроен в TBFS.
Во время нарезки блок переменной длины болтается около 10 Кб, после сжатия он становится 4 Кб.
Делим 690 ТБ на 4 КБ получаем 172 500 000 000 блоков на машине. Это наши "празднующие".
Хеш 32 байта, значит "дней в году" 2^256.
Ну и там дальше это хозяйство подставляем в формулу честную и оцениваем сколько нулей будет или в аппроксимацию, которую можно посчитать математическим пакетом.
Честная формула чтобы получить вероятность что хотя бы у двоих празднующих день рождения совпал
Аппроксимация
Ну T-RAID он все таки не физический контроллер, это софтверное решение. Про него можно тут поподробнее почитать какие сервисы он предоставляет (там как минимум есть scrubber и recovery) https://habr.com/ru/companies/yadro/articles/885320/
У нас есть еще сервисы которые смотрят за его состоянием и управляют T-RAID. Это немного отдельная от TBFS и сложная история.
Сейчас главное, что мы не выдаем втихую некорректные данные. Если на дисках произошла невосстановимая беда, система ответит, что какие-то данные не читаются и зажжет алерт. И аналогичные PBBA тоже проверяют именно это. Если какие-то хеши на каком-то уровне не сошлись - все, пора сообщать пользователю. А восстановление, если возможно - с помощью парити средствами RAID.
И спасибо за историю :) Понятная боль.
Bit rot решаем с помощью RAID + DIF T10. У нас T-RAID из TATLIN.UNIFIED на борту, он позволяет это сделать.
До полностью своего RAID, заточенного на хранение блоков с хешами и красивыми валидациями через это, чтобы запускать пересчеты парити или данных - пока не доросли. Пока вот DIF в дополнение к подписям блоков там считается и сохраняется.
Допустим у меня есть информационная система и я сохранил ее резервную копию 1 января. До этого не было резервных копий. В этом случае резервная копия нарежется на блоки и все блоки будут сохранены, потому что TB их еще не видел.
Когда я пойду сохранять резервную копию той же информационной системы 7 января, TB вычленит изменившиеся регионы файлов и сохранит их на диск. Остальные регионы файла будут адресованы к уже сохраненным блокам. Ну тут в целом понятно что изменений между 1 и 7 января вряд ли много.
А за надежность и избыточность тут RAID отвечает.