Облачное хранилище

Недавно мы столкнулись с проблемой чрезмерного роста базы 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
P.S. в VMware vSphere Management Assistant 5.0 этой проблемы нет, т.к. из него убрали vilogger.
Подробнее и спасибо: http://blog.vmpress.org/http://citrix.pp.ru/