Назад | Перейти на главную страницу

Как правильно отслеживать и контролировать «давление» репликации БД Exchange с течением времени?

Я хочу определить, являются ли некоторые базы данных перегруженными или несбалансированными, и думаю, что просмотр журналов транзакций, созданных для каждой базы данных с течением времени, скажет мне, какая БД подвержена риску пропуска целевых значений RPO из-за высокого ввода-вывода (в основном записи).

Моя идея состоит в том, чтобы создавать график каждой базы данных каждые X минут и подсчитывать каждый созданный журнал.

Поскольку каждый журнал равен 1 МБ в группе E2010 DAG, я могу легко вычислить объем данных, которые могут быть потеряны за заданное время.

Итак, мой вопрос:

  1. Как я могу определить, есть ли у данной базы данных дополнительные операции ввода-вывода, которые лучше перенести в базу данных меньшего объема? Можно ли смотреть на журналы транзакций?

  2. Как мне процедурно определить нагрузку? Возможно, сценарий PowerShell, C #, и экспорт его в график или Excel.

Во-первых, вы можете использовать здесь полезную информацию: http://penetrateit.wordpress.com/2012/02/11/exchange-2010-balancing-the-number-of-mailboxes-and-average-size-across-all-databases/ чтобы выяснить некоторую статистику, необходимую для балансировки почтовых ящиков в базах данных.

Или вы можете использовать здесь сценарий Стива: http://www.stevieg.org/2010/09/balancing-exchange-databases/

Однако позвольте мне предложить дополнительный подход:

  • Если вы еще этого не сделали, настройте свои БД на основе RPO. Имеется в виду создание базы данных VIP и так далее. Поместите эти виртуальные IP-адреса вместе в базу данных, которая, как вы знаете, будет хорошо реплицирована в глобальной сети, и используйте LUN, которые не заполняются для этой базы данных. (ОДНАКО, обратите внимание, что вы не хотите сходить с ума и помещать всех своих часто используемых пользователей в базу данных VIP, иначе вы усугубите свою проблему). Под VIP я имею в виду людей, у которых RPO - «последний час» или аналогичный. Вы даже можете создать базу данных «Meh RPO» и вставить туда кучу несущественных почтовых ящиков, которые вас не волнуют в отношении RPO, тогда, если у вас есть средства для этого в вашей глобальной сети, отмените приоритетность их трафика репликации .

Надеюсь, это поможет.