Архивное дело

[Vtirko]

В соответствие с принятыми 11.03.2019 на совещании принципами, начата реогранизация архивов. Считаю, что необходимо задокументировать эти принципы.

Организация хранения данных. Архивы организуются в виде двух томов, соответствующих имеющимся двум хранилищам:

1. Первое хранилище содержит набор файлов L1B для непосредственной работы с ними и занимает практически весь дисковый объём за вычетом необходимого для обработки данных. Набор файлов L1B организован в виде скользящего окна, начиная с текущей даты назад. Устаревающие файлы архивируются и удаляются сообразно правилам архивирования. По предварительным оценкам длина окна составит около 1,5 года данных.
2. Второе хранилище отведено для накопления архивных материалов, а также всех производных продуктов обработки данных, в частности обзорных изображений.

Правила архивирования

1. Данные MODIS (Terra/Aqua) хранятся в архиве в виде сжатых по алгоритму RAR наборов L1B, что позволяет их относительно быструю распаковку до готовых наборов L1B.
2. Данные VIIRS (Suomi NPP и NOAA-20) хранятся в виде сырых потоков с приёмной станции (RAW). Для работы с такими архивами необходимо обработка каждого файла до уровня L1B, которая занимает значительное время (~1 суток для обработки 1 месяца данных). Способ сохранения вынужденный , так как данные L1B не сжимаются и в несколько раз превосходят по размерам файл RAW.

Реогранизация займёт некоторое время, что связанно с необходимость досчитать некоторые плановые данные для работы, а также включить хранилища в домен RSLAB. Ориентировочная последовательность этапов реорганизации:

1. Перемещение обзорных изображений на второе хранилище.
2. Досчёт "агрокэша" и разработка автоматизации сжатия MODIS с помощью RAR.
3. Перемещение архивных материалов на второе хранилище.
4. Автоматизация управления размером окна данных L1B.
5. Разработка оснастки для автоматизированной обработки (распаковки до L1B) архивных данных.

[derevnya]

По поводу наших СХД.

У нас 2 хранилища по 10 sata дисков в каждом с объемом диска 3.63 Тб. Из 20ти дисков на двоих 4 диска работают на "raid". Остается по 8 дисков на каждом хранилище для реальных данных. *Это 8 3.63 = 29 Тб.**

Итого у нас на каждом хранилище по 29 Тб, плюс технология дедупликации дает еще 3 Тб. Сейчас реально максимум 32 Тб под данные. 3 Тб величина переменная.

А 50 Тб это мифический размер виртуального хранилища, который задается руками.

[Vtirko]

Немного не понял логики вычислений. На не повторяющихся данных дедупликация разве может дать экономию? Ну да ладно. Расскажу, что я выяснил.

Не 50 ТБ, а на самом деле 45 ТБ по данным системы конфигурирования в предконфигурированном варианте конфигурации "infinite volume". Он не задаётся руками, а равен всему объёму RAID. Система для этого варианта конфигурации делает 2 раздела. Один из них "для имён файлов", и его размер она выбирает как 25% от всей ёмкости, но не меньше 10 ТБ (или не больше? — не помню). Второй — для данных файлов. Печально в этом случае то, что объёмы пустого места складываются, а данные в раздел имён не пишутся. Поэтому надо в уме отнимать объём раздела имён (за вычетом занятого места под имена) от суммарного объёма всего свободного места, чтобы определить границу отказа в записи по переполнению места на разделе данных.

Причины такого устройства мне видятся логичными для 2 миллиардов мелких файлов, теневым копиям тома и т.п. технологий хранения предприятия. В нашем же случае мы несём реальные потери места из-за этого в эти самые 10 ТБ.

Поэтому реально записать на эти 45 ТБ, остающиеся после реализации RAID и горячей замены из 60 ТБ, только ~33 ТБ.

Почитать об этом можно тут: https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-ivg%2FGUID-59131371-A4E4-4FAF-A2F1-269E9DCB8C95.html

[derevnya]

Не нашел я там про 25% ничего. Да и цифра 10 Тб на имена файлов выглядит крайне странно. У нас там два nfs диска. Причем один 47, второй 50. B "infinite volume" в одном netapp показывает 47, во втором 50.

Логика простая. У нас на 2 хранилища 20 дисков, физических, с объемом 3.63, если верить показаниям админки. Одно хранилище это 36,3 Тб максимум без учета raid и spare. Откуда 45?

В админке можно посмотреть размер результатов дедупликации на одной ноде. Вот на одной из них указано, что 3 Тб добавилось. Например, нули в снимках дедуплицирует.

[Vtirko]

Я ошибся, 10 ТБ — это максимум для "namespace constituent" — вот тут написано: https://library.netapp.com/ecmdocs/ECMP1196906/html/GUID-8D633101-6AC0-4C10-9080-C9076F5D5243.html Соответственно он и действует на "Infinite volume" больше 40 ТБ.

[derevnya]

Еще раз. У нас физическая емкость одного хранилища 36,6 Тб. А еще минус raid. Откуда у тебя 40, 45, 50?

[Vtirko]

20 дисков по 4 ТБ = 80 ТБ, ещё 4 диска SSD по 400 ГБ быстрый кэш. И это — на каждое хранилище. Из 20 дисков сделано два агрегата по 9 дисков, и 2 диска горячий резерв. Эти 2 агрегата собраны в агрегат, на котором сделан "Infinite volume". Итого 72 ТБ минус чётность (по 2 по 4 ТБ на 2 агрегатах) и прочее — получается ~45 ТБ под разделы "Infinite volume".

[derevnya]

Для архива.

Реально диск 4 Тб = 3.63 Тб.

На одном СХД 8 дисков уходит на "отказоустойчивость", на втором 6. Либо 10 и 8 соответственно. Каждый агрегат ест по 2 диска, агрегат из двух агрегатов 2 диска и само СХД 2 диска (но это не точно). На втором СХД у одного агрегата нет этих двух дисков.

Итого для данных у нас на одном СХД 12 * 3.63 = 43.56 Тб (36.3 Тб по второму варианту), на втором 50.82 Тб (43.56 Тб по второму варианту). Ну и странные 10 Тб на каждый, про которые в настройках нет ничего.

[EPavlichenko]

вот нашел в документации: [-max-namespace-constituent-size {[KB|MB|GB|TB|PB]}] - Maximum Size of Namespace Constituent (privilege: advanced) The maximum size of the namespace constituent. The default value is 10TB. This parameter applies to Infinite Volumes only.

и еще в доках вот такое написано: http://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.onc-sm-help-900%2FGUID-328A0687-17D4-4DAA-B5C1-240BB41EAD60.html

For Storage Virtual Machines (SVMs) with Infinite Volume that use aggregates from two nodes | Data ONTAP considers the node without the namespace constituent and chooses an aggregate with the largest available space.

и еще в текущих настройках смотрю:

размер aggregate ucsmproc::> volume show -volume data Vserver Volume Aggregate State Type Size Available Used%

---

vm01 data - online RW 46.31TB 17.42TB 62%

а здесь, как используется место в этом aggregate - 36,31Тб для данных, 10Тб для constituent(data_ns): ucsmproc::> volume show -is-constituent true Vserver Volume Aggregate State Type Size Available Used%

---

vm01 data_1024_data0001 sata_data_1 online RW 36.31TB 7.43TB 79% vm01 data_ns sata_data_1 online RW 10TB 9.99TB 0% 2 entries were displayed.

вот свободное место на aggregate sata_data_1 (11,92 Tb) ucsmproc::> storage aggregate show -has-mroot false Aggregate Size Available Used% State #Vols Nodes RAID Status

---

sata_data_1 51.42TB 11.92TB 77% online 3 ucsmproc-01 raid_dp, normal

[derevnya]

Почитал тут литературу всякую и посмотрел ролики типа этого: https://www.youtube.com/watch?v=BK6TKesNcTM

Результат:

1. Размер Infinite Volume при создании задается от фонаря.

2. Для нас Infinite Volume подходит лучше чем FlexVol. FlexVol может быть создан только на одном агрегате, а у нас их два.

3. Агрегат над агрегатами у нас лишний и съедает 2 диска зря. Infinite Volume можно было просто создать на двух агрегатах, в этом как раз его основная фишка.

4. Очень мало информации про размеры namespace constituent. Максимум 10 Тб, на namespace и зеркало рекомендуется 25%. Вот максимум из того, что я нашел (все находили): https://library.netapp.com/ecm/ecm_download_file/ECMLP2427453 The namespace constituent and namespace mirror constituents can each consume up to 10 TB of an Infinite Volume's capacity on two or more nodes, depending on the Infinite Volume's size and configuration. The requirements of these namespace-related constituents affect how space is allocated when you create or expand an Infinite Volume. In most cases, the namespace constituent is 10 TB and never larger than 10 TB. However, the namespace constituent is smaller in Infinite Volumes that are relatively small. In small Infinite Volumes, the namespace constituent size is configured so that the combined size of the namespace-related constituents (which includes the namespace constituent and one or more namespace mirror constituents) is equal to 25% of the Infinite Volume's size. For example, if an Infinite Volume is 60 TB and has one namespace mirror constituent, the combined size of the namespace constituent and namespace mirror constituent must be 25% of 60 TB, or 15 TB. That makes the namespace constituent 7.5 TB. If 25% of the Infinite Volume's size would result in namespace-related constituents being larger than 10 TB, the maximum size takes precedence, and each namespace-related constituent is 10 TB.

Но у нас на этом разделе из 10 Тб свободно 9.99 Тб! По идее и здравому смыслу легко можно было бы 9 Тб отобрать, а то и больше. В параметрах изменения раздела есть этот -max-namespace-constituent-size: https://library.netapp.com/ecmdocs/ECMP12452955/html/volume/modify.html

Остается вопрос. Сработает ли он на живой системе и не умрут ли данные. Но выиграть можно более 18 Тб... Можно попробовать запустить команду и посмотреть чего скажет. :)

[Vtirko]

3. Мы когда смотрели агрегат над агрегатами, то не обратили внимание на имена агрегатов. Это - не агрегат над агрегатами, это - совпадение числа дисков и только. 2 агрегата по 9 дисков имеют размер по 400 ГБ, это — системные разделы с которых грузится ОС узлов кластера — по одному на узел. Здесь агрегаты занимают не весь диск, поэтому один диск может входить в несколько агрегатов, что можно посмотреть в свойствах диска..

[derevnya]

In most situations the namespace constituent is 10TB, which allows the Infinite Volume to support 2 billion files. Exceptions include an Infinite Volume that is less than 80TB, or if -max-namespace-constituent-size is set. Setting -max-namespace-constituent-size limits the number of files and directories that can be written to the Infinite Volume. To determine the minimum size of namespace constituent you will need, use (max number of files desired)/2B 10TB. For example, for 1 billion files ((1 billion / 2 billion) 10TB) you would need a total of 5TB. Remember that you need the same size for each of the namespace mirrors. If you set max-namespace-constituentsize, you can do a resize operation to increase the size up to the maximum of 10TB. However, you can never decrease the size.

Set –max-namespace-constituent-size only if you are sure that the Infinite Volume will never need to store 2 billion files. Not setting this option enables the aggregate to have sufficient space to accommodate any growth required if you ever need to support 2 billion files in the Infinite Volume.

[derevnya]

Но это отсюда http://doc.agrarix.net/netapp/tr/tr-4178.pdf Может в новой версии лучше, но не факт.

[EPavlichenko]

http://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.onc-sm-help-900%2FGUID-328A0687-17D4-4DAA-B5C1-240BB41EAD60.html

здесь вроде как написано, что на двух узлах можно отказаться от создания Consituent'а

Еще где-то прочитал, что можно сделать resize Infinte volume с указанием размера Constituent, но размер раздела под Constituent нельзя уменьшить - только увеличить.

т.е. если его надо убить (Constituent) то Infinite Volume надо создавать с нуля с параметром –max-namespace-constituent-size 0.

Ну и команда выше: volume show -is-constituent true, выполненная в терминале, показывает строение Infinite Volume - у него два Volume:

первый - vm01 data_1024_data0001 sata_data_1 online RW 36.31TB 7.43TB 79% под данные.

и второй - vm01 data_ns sata_data_1 online RW 10TB 9.99TB 0% под Constituent.

в конце, в процентах занятое место.

[derevnya]

Мы уже разработали план по выносу со второй хранилки всех данных. И будем создавать ее по новой. Посчитали размер Constituent. Нам хватит 100 Гб, этого хватит на 2 млн файлов. Сейчас у нас около 250к файлов, т.е. 100 Гб это с хорошим запасом.

[derevnya]

На первой хранилке что-то надо делать с диском 1.0.8. Он в spare висит, а его там не должно быть. Мне кажется из-за этого у нас 19 вместо 20.

[derevnya]

Параметры, которые у нас сейчас отличаются: Storage Type: hybrid Hybrid Enabled: true Total Hybrid Cache Size: 744.5GB RAID Status: mixed_raid_type, hybrid, normal RAID Type: mixed_raid_type Is Flash Pool Caching: true

[derevnya]

41Тб, средняя скорость 65Мб/c. Оценка MC 181 час...

[derevnya]

Может SSD кэш приладить?

[derevnya]

После поиска файлов образовались такие ошибки: [20170324202213-aqu] Meta file not found: /2017/20170324/20170324202213-aqu-500.txt [20170317072504-npp] Meta file not found: /2017/20170317/20170317072504-npp-750.txt [20170318052634-npp] Meta file not found: /2017/20170318/20170318052634-npp-750.txt [20170318070609-npp] Meta file not found: /2017/20170318/20170318070609-npp-750.txt [20170320045008-npp] Meta file not found: /2017/20170320/20170320045008-npp-750.txt [20170320062817-npp] Meta file not found: /2017/20170320/20170320062817-npp-750.txt [20170321043237-npp] Meta file not found: /2017/20170321/20170321043237-npp-750.txt [20170321060921-npp] Meta file not found: /2017/20170321/20170321060921-npp-750.txt [20170322055027-npp] Meta file not found: /2017/20170322/20170322055027-npp-750.txt [20170325045631-npp] Meta file not found: /2017/20170325/20170325045631-npp-750.txt [20170326043735-npp] Meta file not found: /2017/20170326/20170326043735-npp-750.txt Это нормально?