Информация

Дата основания
Местоположение
Россия
Сайт
croc.ru
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 15
То есть архивные данные кладутся на SATA и прочие медленные носители, а горячие фрагменты БД, например, на SSD. Причём автоматически и оптимальным образом используются все доступные ресурсы, это не ручная обработка напильником.

Спасибо за статью. Можно у Вас попросить рассказать как Вы определяете какие фрагменты БД горячие, а какие нет? Ну если tempdb все и так понятно… то как это Вы определяете для пользовательских БД.
Для определения температуры данных используется функционал под названием data tiering. Вещь сейчас достаточно известная и распространенная. Tiering делается на блочном уровне. Блоки данных, к которым происходит наиболее частые обращения, размещаются на более быстрых носителях, а те блоки, к которым мало обращений, или их вовсе нет, размещаются на более медленных носителях. Плюс есть технологии, которые позволяют подгрузить сразу в кэш блоки, к которым еще не обращались, но вероятнее всего в скором времени обратятся.

Конкретно в Datacore Tiering работает на блочном уровне по очень простой схеме: SSV оценивает статистику обращения к конкретному блоку, сравнивает с историей, и если блок стал популярнее, то переносит его на быстрые носители. Если наоборот, то на медленные. Оценка и перенос происходит раз в секунду, 30 секунд или минуту. При этом перенос блоков является «неприоритетной» задачей, сначала приложение убедится что у него достаточно ресурсов для чтения и записи, и только потом осуществит перенос. При этом уровней аж 15 штук. Соответственно, и настройки могут быть очень гибкими.
Спасибо за ответ.

Хорошо… Предположим ситуацию. База используется преимущественно на чтение и данные в нее заливаются раз в день.

В контексте SQL Server, когда нам нужно что-то прочитать из БД, то вначале происходят физические чтения с диска, после чего данные помещяются в память (Buffer Pool) и только потом возвращаются на клиент. При таком положении дел, файлы БД будут лежать на медленном носителе и при первой вычитке данных производительность будет не ахти. Если последнее критично, то все эти автоматические плюшки больше вреда принесут. Такие моменты как-то предусматриваются в data tiering о котором Вы упомянули?
Да, базы и прочая OLTP-нагрузка переваривается хорошо. Тьиринг как раз помогает держать систему в нужном тонусе.
Если вы пишите, что производительность критична, то выставляем диску соответсвующий профиль и тьиринг будет держать данные на нужных носителях. Или если по каким-либо причинам вы не хотите привязывать диск к определенному профилю на помощь приходит механизм упреждающего чтения, который работает по следующей схеме:
— если чтение последовательное или укладывается в логику упреждающего чтения, тогда данные очень быстро читаются из кэша
— если чтение блоков носит абсолютно случайный характер, что наименее вероятно в сценарии работы с базами данных, тогда данные действительно будут читаться с того носителя на котором они размещены.
На сколько большой кластер можно собрать? Скажем, если использовать как объектное хранилище (типа Amazon S3), то сколько машин/петабайт можно максимум запихать?
Можно ли растянуть кластер на несколько ДЦ для отказоустойчивости? На сколько хорошо переживает пропадание 1/4 или 1/3 узлов сразу?
Формальное ограничение для коммерческих пользователей (т.е. не требует доп. манипуляций) это 64 хоста и 64PB, соответственно.
Между ДЦ растягивается, такой пример как раз описан в статье (Задача №1), реплицировать м/у площадками можно синхронно, можно асинхронно.
Падение четверти/трети или даже половины узлов никак не скажется на доступности сервиса, но если покрашились строго половинки от синхронных копий, например отрубилась связь с площадкой. Дело в том, что виртуальный диск, который презентует SSV живет строго в двух синхронных физических копиях. Если одну мы потеряли, то хост этого не замечает, если обе, то чуда не происходит и диск более недоступен.
То есть, если по феншую раскидать вирт. диски по хостам, то вероятность потерять сервис минимальна.
Каким образом защищается кэш на запись от сбоев по электропитанию в серверной? Для примера можно взять конфигурацию из описанной вами задачи №1. Весь кластер находится в одной серверной и активно работает. В здании, где расположена серверная, аварийно отключается электропитание. Что будет с данными находящимися в кэше, но еще не записанными на диски? Есть механизмы, которые позволят не потерять их?

Уточнение по ScaleIO. Насколько помню документацию, ScaleIO так же использует ОЗУ серверов под кэширование операций ввода\вывода. Но кэшируются только операции чтения.

Спасибо за статью, читать было интересно :)!
Поддержу вопрос. Что это за такой RAM-кеш на запись? Как обеспечивается сохранность кеша?

Расскажу историю о самом примитивном случае. Был тестовый сервер с кешем контроллера на 128 mb и массивом RAID5 на 3 Tb. Бекапа кеша не было. Вроде бы казалось что такое 128Mb vs 3Tb. Как плотник супротив столяра. Контроллер вышел из строя. ВСЕ полезные данные на томе пришли в негодность. Все SQL БД и все включенные виртуальные машины оказались неисправимо повреждены. С тех пор RAM кешей без батареек мы как огня.
К сожалению, даже самые невероятные аварии случаются и уносят миллионы. Примеров десятки реально, начиная от двух строек с забитыми сваями в европейском магистральном кольце с разрывом в 2 часа.
Спасибо за вопрос. Если виртуальный диск живет на двух нодах, запитанных от одного источника, то им точно нужен ИБП, без вариантов, в кэше никаких батареек нет, т.к. это самая обычная RAM x86. ИБП рекомендуется пользовать дружащий с виндой, чтобы датакор знал в каком он состоянии, т.е. на батарейке — выключаем кэш на запись, мало батарейки — нода просит соседку включить журнал рассинхронизации, а сама выключается.
В нашем случае (Задача 1) есть диски, как живущие в одном ЦОД, (условно vDisk1 на картинке) так и аля «метрокластре», т.е. одна копия в ЦОД, вторая в РЦОД (vDisk2 и vDisk3).

ScaleIO — так и есть, спасибо за уточнение.
Спасибо за ответ. Отвлеченно скажу, что у нас славные стоечные ИБП APC не раз уносили стойку в сборе ) Переподключили по науке, от двух источников.
Лицензируется DC по объёму — пачками по 8, 16 ТБ.

По объему на сервер или всего с любым количеством серверов? В первом случае это не конкурент СХД начального уровня при отсутствии второго сайта.

Кстати, какие там требования по latency и пропускной способности?
По лицензированию, учитывается каждый узел, к нему объем, который нужно виртуализировать, плюс отдельно опции, например, FC и CDP входят не во все базовые лицензии. По небольшим одиноким СХД — тут не поспоришь, хорошее исключение — это высоконагруженные системы с раскладом: много иопсов — мало объема, тут обычный сервак в PCI-SSD картой и датакором прям поборются.
Что касается пропускной способности и задержки, то со стороны системы временных ограничений для синхронной репликации кэшей нет, реальные требования диктуются хостом, т.е. сколько приложение готово ждать ответа и именно эти требования должны быть основой для сайзинга, а именно — какие использовать тип протокола, тип HBA и максимально возможное расстояние между ЦОДами (например, оптоволокно дает 5 мкс задержки на 1 километр).
Сам Datacore — low latency app, т.е. значимых задержек не вносит. Лучшее что видел мой иометер это 0,14 милисекунд с синхронной репликацией.
Интересная статья. А есть ли пример развертывания системы именно для «зоопарка» техники?
Из красиво описанных есть пример конторы Continuum health partners, они как раз начинали с объединения несовметсимых стораджей, и плавно доросли до 2х петабайт.
Можно посмотреть или прочитать.
Но там про сам зоопарк разве что идея, деталей нет.
На практике же зоопарк в проектах виртуализации встречается регулярно. Из недавнего, казалось бы, простая задача, зеркалировать данные в формально «гомогенной» среде между трипаром и ивой, везде FC плюс имеются N штук MSA и пара P2000, нужно распределить коробки по 2-м площадкам и зеркалировать данные. Понятно, что SSV не единственное решение, но закрывает вопрос легко, добавляется пара не менее «гомогенных» серверов, на них Datacore и полетели, причем кэш и возможность подкинуть в сам сервер SSD или лучше PCI-SSD уравновешивают производительность площадок. Тут формально не зоопарк, а больше сложности внутри семейства, но подход абсолютно тот же.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.