Углубление объема данных создаст массу проблем.

В старые добрые времена, файлы хранились на жестком диске или магнитной ленте. И учитывая огромную разницу между ценой и производительностью этих двух способов, было очевидно, какие файлы и где хранились. Но с появлением устройств флеш-памяти, а теперь и памяти класса хранения (SCM), понять всё же где хранить данные стало сложнее.

Эта проблема была первой в обсуждении с главным архитектором программного обеспечения Panasas, Кертисом Андерсоном на прошлой недели в Next I/O Platform event. И как объяснил Андерсон, перемещение с двух до четырёх уровней хранения — это не просто вопрос удвоения иерархии. С учётом разнообразия, обеспечиваемого этими новыми слоями хранения, трудно понять, когда нужно продвигать файлы на более быстрые уровни или снижать их до более медленных.

“Раньше считалось, что алгоритм LRU был лучшим способом управления увеличения и уменьшения хранилища”, — объяснил Андерсон. “Сейчас отрасль движется в ту сторону прогностической аналитики, которая сможет предсказать, когда данные будут более или менее востребованы”. 

Конечно, это подразумевает то, что у вас имеется определённая система управлениями файлов, чтобы знать результаты этой аналитики. По словам Андерсона, разработка такой политики, вызвала затруднения для большинства сайтов в настоящее время. С его точки зрения, клиент в Panass, имеет только общее представление о требованиях хранения своих рабочих нагрузок, поэтому придумывание правил управления файлами вокруг многоуровневого хранения, практически невозможно. В этом случае, они будут надеяться на своего поставщика хранилища, чтобы те помогли им. Но даже Андерсон признаёт, что придумывание единой политики для сайта, требует достаточное количество опыта.

Разнообразие этих новых устройств хранения данных, также добавляет проблем. К примеру флеш-устройство SATA оптимизировано для ёмкости, а устройство NVM-Express оптимизировано для производительности. Это предполагает, что любая политика, которая разрабатывается вокруг этих flash-устройств, должна основываться на их особенностях.

Память, такого типа хранения, как Intel’s Optane Persistent Memory, имеет другой набор проблем. Во-первых, SCM является новым направлением, которое ни каждый сможет понять. 

Дополнительная сложность заключается в том, что в случае постоянной памяти Optane, в любой момент она может быть использована, как облачное запоминающее устройство, либо, как расширитель основной памяти. В последнем случае, система перестаёт являться частью системы хранения, поэтому использование в любом направлении, должно будет исходить из разносторонних применений.

Андерсон отметил, что культура вокруг хранения данных, также меняется, по крайней мере, на арене HPC, которой он пользуется. Наглядно это показывает меняющееся мышление разработчиков приложений. В прошлом, традиционные программисты HPC, хорошо понимали, как производительность их приложения может быть ускорена параллельной файловой системой. Поэтому они разрабатывали своё программное обеспечение исходя из этого. Тем не менее, новое мышление разработчиков приложений, в таких областях, как AI and genomics, имеют только смутное представление о том, как их коды влияют на файловую систему и оборудование для хранения данных. В результате, сказал Андерсон “Мы больше не получаем поддержки от авторов приложения”.

Ещё одним важным изменением, считается исчезновение администраторов хранилища HPC. Поскольку для управления такой сложной системой, требуются определённые навыки, такие люди всегда были востребованы. По оценке Андерсона, такой работник будет стоить организации около 200 000 долларов в год. Один только миллион, можно потратить на штат из пяти человек. 

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

Источник: http://leisurecentre.ru/flash-nakopiteli-uxodyat-v-proshloe/