Хранение большого количества состояний в кластере Service Fabric

У меня есть сценарий, в котором нам нужно хранить x * 100 ГБ данных. Данные в целом являются хорошим кандидатом на постоянное состояние для субъекта (хорошо разделенного, используемого только определенными субъектами) в самом кластере сервисной фабрики.

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

Как объем постоянного состояния влияет на задержку перемещения разделов между узлами в кластере?


person Pragya    schedule 02.02.2016    source источник


Ответы (1)


Что ж, давайте посмотрим, как сохраняется состояние в сервисе (это относится и к акторам).

Компонент, который хранит ваши данные в вашей службе, называется поставщиком состояний. Поставщики состояний могут быть только в памяти или в памяти + на локальном диске. Поставщик состояния по умолчанию, который вы получаете со службой актора, находится в памяти + локальный диск, но он хранит только горячие данные в памяти, поэтому ваши требования к хранилищу не привязаны к памяти. В отличие от поставщика состояния Reliable Collections, который в настоящее время хранит все данные как в памяти, так и на локальном диске, хотя в будущем выпуске у него также будет возможность хранить только горячие данные в памяти и выгружать остальные на локальный диск.

Учитывая, что вы используете акторов, вы можете использовать поставщика состояний акторов по умолчанию, что означает, что емкость ваших данных ограничена локальным дисковым хранилищем на ваших машинах или виртуальных машинах, что должно быть разумным для хранения сотен ГБ. Обычно мы не перемещаем целые разделы, но иногда Service Fabric требуется перестроить реплику службы, и чем больше у вас данных, тем больше времени потребуется для создания реплики. Однако на самом деле это не влияет на задержку вашей службы, потому что у вас есть несколько реплик в службе с отслеживанием состояния, и у вас обычно достаточно реплик, чтобы вам не нужно было ждать, пока другая будет перестроена. Восстановление реплики обычно происходит «в стороне».

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

person Vaclav Turecek    schedule 03.02.2016