Именно в таком ключе происходит мое общение с вендором последние дни. У нас началась фаза реализации проекта по Росплатформе и как бы я сильно не готовился к внедрению этого продукта - все приготовления оказались недостаточными. Помимо проблем, на которые я описал решения в разделе trouble хочу выделить следующие:
Сотрудник который был выдан мне в помощь гонял меня по бесполезным заданиям целый день безрезультатно, хотя как я сейчас понимаю, судя по отчетам которые я предварительно для него подготовил должен был написать пачку скриптов которые для моей системы привели бы все в целевое состояние. В итоге я решил проверить самостоятельно все возможные варианты добавления дисков через веб-интерфейс и убедился что автомат распределения нагрузки на SSD диски в моей конфигурации точно сломан и нормального результата не даст.
Вендором была предложена следующая методика восстановления:
vstorage -c имя кластера configure-cs -r /vstorage/IDчанкСервиса/cs -a /vstorage/IDдискаSSDcКЭШ/journal/ИмяФайлажурналаСчанкаСервиса -s 75776
, где 75776- размер журнала в МБ. Использовать данную методику я не стал, потому что во первых ее прислали слишком поздно и я уже половину серверов сделал по своему методу с изменением размера журнала, во вторых мне не до конца понятно как формировать строки пути, потому что в оригинале они выглядят как некий UUID и возможно веб интерфейс к этому привязывается. Поэтому я решил нанести минимальный ущерб веб интерфейсу и плавно его подтолкнуть к созданию журнала в нужном месте путем исправления ошибок которые веб интерфейс допускает.
В сухом остатке имеем следующие трудозатраты в рабочих часах:
Еще раз хочу напомнить ссылку которая сэкономит вам как минимум неделю страданий: trouble