Paromshick
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Немного набросаю скопом
Если базу в три Т "размигрировать" в другие пять баз, то суммарный объем всех баз будет меньше той, из которой мигрировали. Актуально сие утверждение для старой базы, которая давно на офлайн дефрагментацию напрашивалась. Там у нее куча пустого места завалялась. Пустое место переезжать не будет, отсюда и разница.
При миграции распухают журналы, надо это учесть.
Не думаю, что есть какой-то бэст, как лучше базы разбивать. Что и было сказано, присоединяюсь.
Смотреть надо по хранилищам, об этом писал ранее. Тут можно нащупать некую "лучшесть", типа часто используемые и активные ящики лежат на быстром хранилище, а архивные и другие "мертвые", хоть на iSCSI, с интерфейсом в сто М. Подождут.
Но. Опять же, приятно Президенту Ко, когда, у него и основной ящик, и архивные папки "летают". Значит есть исключения из правил. Либо - нет. Всем строится, я тут админ  Каждый смотрит сам.
Я бы разбивал базы исходя из быстродействия хранилищ, а уж чьи ящики там будут жить - вопрос второй.
Если хранилище всё-таки одно, то не надо делать одну базу.
Надо задуматься о бэкапах, и о масштабируемости. Бэкапы пяти баз в сто гиг легче проходят, чем одной в 500, да и разбросать архивы можно.
Масштабируемость.., ну, например, учесть сакральные числа, возникающие из 2n.
Столкнулся тут с тем, что на VMware 5 не может быть файл больше 2048G, то есть 2Т, а значит и не может быть диска, большего объема на виртуалке. Это в общем, и простом случае.
Скажете, при чём здесь exchange... Да вот, захочу я (вдруг) сделать MB сервер на виртуалке и посунуть ему диск более 2Т под базу, но уткнусь в то, что такого диска быть не может. Я такой диск я создать не могу, by design. Абыдна. Не могу сделать MB сервер в филиале, где всё давно на VMv... Конечно, мы решим этот вопрос, так или иначе в VMv, но это не унифицированное решение. Здесь так, а тут через это... Наколеночное решение.
Костыли и танцы с бубнами уже не интересны в итоге, поймите.
Проще и правильнее сделать (запланировать) базу меньше. Изначально.
Конечно, оно распухает, но и тут можно подумать, не всё ж пятой точкой стул давить.
Вот и пример, что будет, если диск в 500G, а база распухает и прёт выше? Алерт будет. Естественно. Недостаточно места на диске. Со всеми проистекающими.
Но, если в этой базе 25 ящиков и у каждого ограничение в 2048 (!) Мегабайта, то такого не может быть. Хотя... даже тогда такое может быть. Так что лучше 20 ящиков. Но и ограничения постоянно снимаются, разве нет? Дир говорит, мне надо! и админ отвечает есть! Как-то так.
Таким образом, мы плавно и правильно перетекаем в тему: системы мониторинга... PRTG, мне нравится.
|
Скорее, нужно - ведь выходят исправления не только безопасности, а еще и какие-то улучшалки, фиксы багов и т.д. По моему опыту - проблема может решиться сама собой если продукт банально обновить до актуальной версии.
