В комментариях к нашему посту об архитектуре 3Par InServ нас попросили подробнее рассказать как реализован у 3Par механизм thin reclamation. Работа по вашим заявкам — это, наверное, самая приятная часть ведения этого блога, поэтому с удовольствием рассказываем.
Прежде всего давайте посмотрим зачем, собственно, требуется thin reclamation. 3Par, а вслед за ней и другие вендоры дисковых массивов применили в своих системах технологию thin provisioning, которая позволяет выделять приложениям емкость из виртуального пула дисковых ресурсов. При этом выделенная виртуальная емкость может быть намного больше, чем физическая, за счет чего можно существенно сэкономить на дисках при покупке массива.
Хорошее решение. Но существует проблема. Если приложение освободит часть этой виртуальной емкости, или выяснится, что ему была выделена лишняя виртуальная емкость, то на физическом уровне диски, которые соответствуют этой освобожденной виртуальной емкости, всё равно останутся за этим приложением и их нельзя передать другим приложениям.
Например, рассмотрим такой сценарий: файловая система хоста содержит 100 Гб данных и ей выделена такая же емкость из виртуального тома на дисках массива. Если удалить группу файлов общим размером 10 Гб, то массив не сможет узнать об этом удалении и для файловой системы на нем по-прежнему будет выделено 100 Гб.
Если затем вместо старых файлов будут записаны новые того же объема, то для них потребуется выделить дополнительно 10 Гб емкости на дисках, хотя размер самой файловой системы останется прежним — 100 Гб. В результате тонкий том (thin volume) будет постепенно разрастаться и становиться толстым (fat volume).
Для решения этой проблемы 3Par добавила в операционную систему InServ функцию Thin Persistence (вольный перевод — поддержание томов в спортивной форме). Thin Persistence работает в реальном времени и анализирует данные перед тем, как они будут записаны в тонкий том. В данных, которые пишет хост, функция ищет блоки, состоящие из одних нулей (это служит признаком затертых данных или неиспользованной емкости), и затем возвращает эти блоки порциями по 16 Кбайт в пул свободной виртуальной емкости. Функция поиска нулей встроена в специализированную микросхему 3Par ASIC Gen3 и поэтому Thin Persistence не замедляет работу массива InServ Storage Server.
Аналогичным способом работает и функция Thin Copy Reclamation. С той разницей, что она борется с утолщением томов, которое происходит из-за удаления мгновенных снимков (snapshot), а не файлов. При удалении мгновенного снимка выделенная ему емкость виртуального тома возвращается в виртуальный пул и может быть перераспределена между другими томами.
Особо стоит сказать о том, что 3Par, как пионер технологии thin provisioning, первой среди производителей дисковых массивов реализовала поддержку API-интерфейсов Thin Reclamation для Veritas Storage Foundation версии 5 и выше. С помощью них работающая на хосте файловая система VxFS сама сообщает дисковому массиву (SCSI-командой WRITE SAME) об удалении файлов, поэтому массив InServ Storage Server может найти выделенную этим файлам емкость без поиска блоков нулей (подробнее об этом здесь).
Кроме того, Oracle совместно с 3Par разработали утилиту Oracle Automatic Storage Manager (ASM) Storage Reclamation для высвобождения емкости для СУБД Oracle Database 10g и 11g на дисковых массивах InServ Storage Server (подробнее здесь).
Надеемся, что было интересно.
Прежде всего давайте посмотрим зачем, собственно, требуется thin reclamation. 3Par, а вслед за ней и другие вендоры дисковых массивов применили в своих системах технологию thin provisioning, которая позволяет выделять приложениям емкость из виртуального пула дисковых ресурсов. При этом выделенная виртуальная емкость может быть намного больше, чем физическая, за счет чего можно существенно сэкономить на дисках при покупке массива.
Хорошее решение. Но существует проблема. Если приложение освободит часть этой виртуальной емкости, или выяснится, что ему была выделена лишняя виртуальная емкость, то на физическом уровне диски, которые соответствуют этой освобожденной виртуальной емкости, всё равно останутся за этим приложением и их нельзя передать другим приложениям.
Например, рассмотрим такой сценарий: файловая система хоста содержит 100 Гб данных и ей выделена такая же емкость из виртуального тома на дисках массива. Если удалить группу файлов общим размером 10 Гб, то массив не сможет узнать об этом удалении и для файловой системы на нем по-прежнему будет выделено 100 Гб.
Если затем вместо старых файлов будут записаны новые того же объема, то для них потребуется выделить дополнительно 10 Гб емкости на дисках, хотя размер самой файловой системы останется прежним — 100 Гб. В результате тонкий том (thin volume) будет постепенно разрастаться и становиться толстым (fat volume).
Для решения этой проблемы 3Par добавила в операционную систему InServ функцию Thin Persistence (вольный перевод — поддержание томов в спортивной форме). Thin Persistence работает в реальном времени и анализирует данные перед тем, как они будут записаны в тонкий том. В данных, которые пишет хост, функция ищет блоки, состоящие из одних нулей (это служит признаком затертых данных или неиспользованной емкости), и затем возвращает эти блоки порциями по 16 Кбайт в пул свободной виртуальной емкости. Функция поиска нулей встроена в специализированную микросхему 3Par ASIC Gen3 и поэтому Thin Persistence не замедляет работу массива InServ Storage Server.
Аналогичным способом работает и функция Thin Copy Reclamation. С той разницей, что она борется с утолщением томов, которое происходит из-за удаления мгновенных снимков (snapshot), а не файлов. При удалении мгновенного снимка выделенная ему емкость виртуального тома возвращается в виртуальный пул и может быть перераспределена между другими томами.
Особо стоит сказать о том, что 3Par, как пионер технологии thin provisioning, первой среди производителей дисковых массивов реализовала поддержку API-интерфейсов Thin Reclamation для Veritas Storage Foundation версии 5 и выше. С помощью них работающая на хосте файловая система VxFS сама сообщает дисковому массиву (SCSI-командой WRITE SAME) об удалении файлов, поэтому массив InServ Storage Server может найти выделенную этим файлам емкость без поиска блоков нулей (подробнее об этом здесь).
Кроме того, Oracle совместно с 3Par разработали утилиту Oracle Automatic Storage Manager (ASM) Storage Reclamation для высвобождения емкости для СУБД Oracle Database 10g и 11g на дисковых массивах InServ Storage Server (подробнее здесь).
Надеемся, что было интересно.
