Недавно мы столкнулись с проблемой чрезмерного роста базы VMware vCenter Server.
Все началось с того, что один из серверов ESXi в нашей тестовой лаборатории упал в ‘пурпурный экран смерти’.
По коду ошибки удалось определить и устранить проблему, однако, после перезагрузки никаких журналов событий на сервере ESXi не сохранилось. Было решено вести централизованный сбор журналов с помощью vSphere Management Assistant. Сказано — сделано, несколько команд в консоли (решили заодно собирать журналы с сервера vCenter), проверка, что журналы в vMA обновляются, и о проблеме забыли. Пока через несколько дней внезапно не отключился vCenter Server. Журнал приложений в Windows показал, что база vCenter заняла максимально возможные 10 Гб (в качестве СУБД мы используем Microsoft SQL Server 2008 R2 Express Edition), что, собственно, и послужило причиной остановки vCenter.
С помощью сценария мы быстро определили размер всех таблиц в базе.
SET NOCOUNT ON DBCC UPDATEUSAGE(0) -- DB size. EXEC sp_spaceused -- Table row counts and sizes. CREATE TABLE #t ( [name] NVARCHAR(128), [rows] CHAR(11), reserved VARCHAR(18), data VARCHAR(18), index_size VARCHAR(18), unused VARCHAR(18) ) INSERT #t EXEC sp_msForEachTable 'EXEC sp_spaceused ''?''' SELECT * FROM #t -- # of rows. SELECT SUM(CAST([rows] AS int)) AS [rows] FROM #t DROP TABLE #t
Самыми большими оказали таблицы VPX_EVENT и VPX_EVENT_ARG — вместе с индексами они занимали более 9.5 Гб. С кем не бывает — подумали мы, хотя и усомнились, т.к. наша тестовая лаборатория не такая большая, чтобы в журналах сохранялось так много событий. Для очистки таблиц мы использовали сценарий с сайта VMware:
TRUNCATE table VPX_EVENT_ARG DELETE FROM VPX_EVENT
Если вы планируете последовать нашему примеру — приготовьтесь к тому, что выполнение сценария потребует много времени и приведет к существенному увеличению размера журналов базы (в конце статьи приведен альтернативный сценарий). Поскольку в качестве Recovery Model установлен режим Simple, то после завершения операции мы сделали Shrink Database, и база уменьшилась до 350 Мб.
Однако, через некоторое время после включения служб vCenter база снова стала расти гигантскими темпами. Для определения причины проблемы заглянули vCenter Server log и обнаружили огромное количество записей о подключении vSphere Management Assistant к серверу vCenter.
Для проверки мы выключили на время виртуальную машину с vMA, и база перестала расти. Поскольку сам vMA был установлен достаточно давно, то стало понятно, что проблема возникла из-за недавних манипуляций с vilogger. Отключение сбора журналов с сервера vCenter позволило решить проблему. Уже потом, ища более простой способ очистки базы от событий, мы обнаружили, что не первые, кто столкнулся с данной проблемой, более того — есть соответствующая статья в базе знаний VMware. Вот код от vfrank.org:
alter table VPX_EVENT_ARG drop constraint FK_VPX_EVENT_ARG_REF_EVENT, FK_VPX_EVENT_ARG_REF_ENTITY alter table VPX_ENTITY_LAST_EVENT drop constraint FK_VPX_LAST_EVENT_EVENT truncate table VPX_TASK truncate table VPX_ENTITY_LAST_EVENT truncate table VPX_EVENT truncate table VPX_EVENT_ARG alter table VPX_EVENT_ARG add constraint FK_VPX_EVENT_ARG_REF_EVENT foreign key(EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade, constraint FK_VPX_EVENT_ARG_REF_ENTITY foreign key (OBJ_TYPE) references VPX_OBJECT_TYPE (ID) alter table VPX_ENTITY_LAST_EVENT add constraint FK_VPX_LAST_EVENT_EVENT foreign key(LAST_EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade