Журналы Service Fabric занимают все доступное дисковое пространство.

У меня есть несколько кластеров, которые уже работают около месяца, и я обнаружил, что временное хранилище полностью поглощается файлами журнала Service Fabric. На приятном парке виртуальных машин F1, где есть только 16 ГБ локального хранилища, мне почти не хватает места, некоторые из них теперь сократились до 30 МБ, да мегабайты хранилища (где мое приложение потребляет менее 1 ГБ в все его варианты).

Глядя на использование диска на виртуальных машинах кластера, я ясно вижу, что папки SvcFab\Log и SvcFab\ReplicatorLog занимают более 90% доступного пространства. Конечно, SF может лучше справиться с этим. Есть ли что-то, что я могу переключить или настроить, чтобы заставить его сбросить некоторые данные? Или еще лучше переместить его в хранилище больших двоичных объектов или таблиц?

Это должно быть проблемой для других. Что делают другие? И команда Service Fabric, как лучше всего это сделать?


azure-service-fabric
person BrettRobi    schedule 04.10.2016    source источник
comment
что касается хранилища больших двоичных объектов, интересно, пытались ли вы добавить учетные записи хранения в Microsoft.Compute/virtualMachineScaleSets: «Microsoft.Storage/storageAccounts», «supportLogStorageAccountName»   -  person Rotem Varon    schedule 05.10.2016
comment
По умолчанию в кластер добавляются три учетные записи хранения (через доступные шаблоны ARM). Один из них явно предназначен для журналов, и я вижу кучу счетчиков производительности и различных файлов журналов, но, похоже, SF неправильно поддерживает локальные папки Log и ReplicatorLog в отношении использования дискового пространства.   -  person BrettRobi    schedule 05.10.2016
comment
@BrettRobi, вы когда-нибудь находили лучшее решение для этого? Я сталкиваюсь с этим, и это чертовски раздражает меня   -  person BBlake    schedule 14.03.2017
comment
@BBlake нет, я этого не делал. С тех пор я перешел на инстансы A1, которые решают проблему из-за гораздо большего объема локального хранилища, но с потерей вычислительной мощности.   -  person BrettRobi    schedule 15.03.2017

Ответы (3)


arrow_upward
0
arrow_downward

Если журнал репликатора заполнен, это означает, что вы используете F1 для хранения данных ... 16 ГБ - это немного для вашего хранилища данных, и вам может быть лучше разбить приложение на службы обработки / хранения с различными наборами.

Не эксперт в том, как SF хранит вещи (я оставлю это и обрежу другим, но там не так много информации), но если это похожие решения, то в журнале репликатора есть часть ваших данных, и он уменьшается, когда безопасно. Кроме того, вместо F1 вам может быть лучше использовать F2 и F4, поскольку они имеют * 2 или * 4 ввода-вывода и ядер, вы ничего не теряете, но получаете дополнительное хранилище ... и это означает меньшую репликацию (если вы не делаете много разделов).

person user1496062    schedule 05.10.2016
comment
Нет, на самом деле у меня в настоящее время есть одна очень простая служба без сохранения состояния в этом кластере. У меня нет локальных данных. Вы хорошо замечаете увеличение размера виртуальной машины, но тогда мне не нужна ни вся эта вычислительная мощность, ни оперативная память. И, честно говоря, не похоже, что мне нужно управлять или беспокоиться о хранении данных SF, только о моих собственных. - person BrettRobi; 05.10.2016

arrow_upward
0
arrow_downward

Так что никакой полезной помощи по этому вопросу. Я прибегаю к сносу этого кластера и его восстановлению. К счастью для меня, кластер был одним из пары, и я смог просто перенаправить весь трафик через TrafficMgr на другой кластер, пока я уничтожил неисправный и создал новый.

Меня довольно смущает. Если бы у меня не было этой избыточности, это была бы довольно большая проблема. :-(

person BrettRobi    schedule 31.10.2016
comment
Подобные проблемы заставляют меня задуматься, а не является ли Service Fabric хорошей идеей... (В настоящее время оцениваю Service Fabric для своей компании.) - person Vaccano; 21.04.2017

arrow_upward
0
arrow_downward

Я не уверен, что нижеприведенное считается разрушением кластера! Я протестировал это на сервисе без сохранения состояния в фиктивном приложении Service Fabric.

Структура служб, которую мы развернули на Standard_DS1_V2, страдала от потери кворума, и служба анализа работоспособности также не работала из-за нехватки места на диске. Вместо того, чтобы снести кластер, я остановил масштабируемый набор виртуальных машин с помощью ARM power shell.

stop-azurermvmss -ResourceGroupName "RG" -VMScaleSetName "VMSS"

Затем перейдите на портал Azure > Группы ресурсов > Масштабируемый набор виртуальных машин > Масштабирование, чтобы увеличить номер SKU до Standard_D1_V2, и запустите масштабируемый набор виртуальных машин.

start-azurermvmss -ResourceGroupName "RG" -VMScaleSetName "VMSS"

и повторно развернул приложение Service Fabric, и оно работает так, как ожидалось!

person ManiVI    schedule 01.06.2017