Внедрение любого ИТ-решения на предприятии начинается с проектирования. На данном этапе ИТ-менеджеру предстоит рассчитать количество серверов и их характеристики, чтобы их с одной стороны с запасом хватало на всех пользователей, а с другой, чтобы соотношение цены и качества этих серверов было оптимальным и затраты на создание вычислительной инфраструктуры для новой информационной системы не пробили серьезную брешь в ИТ-бюджете предприятия. Давайте же разберемся, как следует проектировать инфраструктуру для внедрения на предприятии Zimbra Collaboration Suite.
Основной особенностью Zimbra в сравнении с другими решениями является то, что в случае с ZCS «бутылочным горлышком» редко становится процессорная мощность или оперативная память. Основным ограничением обычно становится скорость ввода и вывода жесткого диска и поэтому основное внимание следует уделить именно хранилищам данных. Официально заявленными минимальными требованиями для Zimbra в производственной среде являются 4-ядерный 64-битный процессор с 2 гигагерцами тактовой частоты, 10 гигабайт под системные файлы и логи, а также от 8 гигабайт ОЗУ. Обычно таких характеристик хватает для отзывчивой работы сервера. Но что делать, если вам предстоит внедрить Zimbra для 10 тысяч пользователей? Какие серверы и как следует внедрять в таком случае?
Начнем с того, что инфраструктура на 10 тысяч пользователей должна быть мультисерверной. Мультисерверная инфраструктура с одной стороны позволяет сделать Zimbra масштабируемой, а с другой, добиться отзывчивой работы информационной системы даже при большом наплыве пользователей. Обычно бывает довольно сложно предсказать, сколько именно пользователей сможет качественно обслужить сервер Zimbra, так как очень многое зависит от интенсивности их работы с календарями и электронной почтой, а также от используемого протокола. Именно поэтому для примера мы внедрим 4 почтовых хранилища. В случае недостатка или серьезного избытка мощностей можно будет либо отключить, либо добавить еще один.
Таким образом, при проектировании инфраструктуры на 10.000 человек потребуется создать серверы LDAP, MTA и Proxy и 4 почтовых хранилища. Отметим, что серверы LDAP, MTA и Proxy можно сделать виртуальными. Это позволит сократить издержки на серверное оборудование и облегчит резервирование и восстановление данных, но с другой стороны, в случае отказа физического сервера, вы рискуете оказаться сразу без MTA, LDAP и Proxy. Именно поэтому выбор между физическими или виртуальными серверами следует делать исходя из того, какое время простоя вы можете себе позволить в случае ЧП. Почтовые хранилища же лучше всего будет разместить на физических серверах, так как именно на них будет происходить основное количество циклов записи, которые и ограничивают быстродействие Zimbra, и поэтому большее количество каналов для передачи данных позволит значительно увеличить производительность Zimbra.
В принципе, после создания серверов LDAP, MTA, Proxy, сетевых хранилищ и объединения их в единую инфраструктуру, Zimbra Collaboration Suite на 10000 пользователей готова к вводу в эксплуатацию. Схема работы такой конфигурации будет достаточно простой:
На схеме отображены основные узлы системы и потоки данных, которые будут между ними циркулировать. При такой конфигурации инфраструктура будет совершенно не защищена от потери данных, простоя, связанного с выходом из строя какого-либо из серверов и так далее. Давайте же посмотрим на то, как именно можно защитить свою инфраструктуру от этих проблем.
Основной метод — это аппаратная избыточность. Дополнительные узлы MTA и Proxy могут в случае выхода из строя главных серверов, временно взять на себя роль основных. Дублирование узлов критически важной инфраструктуры практически всегда является отличной идеей, но не всегда она реализуема в желаемом объеме. Яркий пример — резервирование серверов, на которых хранится почта. В настоящее время Zimbra Collaboration Suite Open-Source Edition не поддерживает создание дублирующих хранилищ, поэтому в случае отказа одного из таких серверов избежать простоя не получится, и для снижения времени простоя, вызванного отказом почтового хранилища, ИТ-менеджер может развернуть его резервную копию на другом сервере.
Так как встроенной системы резервного копирования в Zimbra OSE нет, то нам понадобится Zextras Backup, поддерживающий резервирование в реальном времени, и внешнее хранилище. Поскольку Zextras Backup, осуществляя снятие полных и инкрементальных резервных копий, складывает все данные в папку /opt/zimbra/backup, было бы разумным подмонтировать в нее внешнее, сетевое или даже облачное хранилище, чтобы в случае падения одного из серверов иметь на руках носитель с актуальной на момент ЧП резервной копией. Развернуть ее можно как на резервном физическом сервере, так и на виртуальной машине и в облаке. Неплохой идеей также будет установить MTA со спам-фильтром перед сервером с Zimbra Proxy, чтобы снизить количество поступающего на сервер мусорного трафика.
В итоге защищенная инфраструктура Zimbra будет выглядеть примерно так:
При такой конфигурации инфраструктура Zimbra не только сможет обеспечить предоставление качественных услуг 10.000 пользователям, но и в случае возникновения нештатной ситуации позволит максимально быстро устранить ее последствия.
Основной особенностью Zimbra в сравнении с другими решениями является то, что в случае с ZCS «бутылочным горлышком» редко становится процессорная мощность или оперативная память. Основным ограничением обычно становится скорость ввода и вывода жесткого диска и поэтому основное внимание следует уделить именно хранилищам данных. Официально заявленными минимальными требованиями для Zimbra в производственной среде являются 4-ядерный 64-битный процессор с 2 гигагерцами тактовой частоты, 10 гигабайт под системные файлы и логи, а также от 8 гигабайт ОЗУ. Обычно таких характеристик хватает для отзывчивой работы сервера. Но что делать, если вам предстоит внедрить Zimbra для 10 тысяч пользователей? Какие серверы и как следует внедрять в таком случае?
Начнем с того, что инфраструктура на 10 тысяч пользователей должна быть мультисерверной. Мультисерверная инфраструктура с одной стороны позволяет сделать Zimbra масштабируемой, а с другой, добиться отзывчивой работы информационной системы даже при большом наплыве пользователей. Обычно бывает довольно сложно предсказать, сколько именно пользователей сможет качественно обслужить сервер Zimbra, так как очень многое зависит от интенсивности их работы с календарями и электронной почтой, а также от используемого протокола. Именно поэтому для примера мы внедрим 4 почтовых хранилища. В случае недостатка или серьезного избытка мощностей можно будет либо отключить, либо добавить еще один.
Таким образом, при проектировании инфраструктуры на 10.000 человек потребуется создать серверы LDAP, MTA и Proxy и 4 почтовых хранилища. Отметим, что серверы LDAP, MTA и Proxy можно сделать виртуальными. Это позволит сократить издержки на серверное оборудование и облегчит резервирование и восстановление данных, но с другой стороны, в случае отказа физического сервера, вы рискуете оказаться сразу без MTA, LDAP и Proxy. Именно поэтому выбор между физическими или виртуальными серверами следует делать исходя из того, какое время простоя вы можете себе позволить в случае ЧП. Почтовые хранилища же лучше всего будет разместить на физических серверах, так как именно на них будет происходить основное количество циклов записи, которые и ограничивают быстродействие Zimbra, и поэтому большее количество каналов для передачи данных позволит значительно увеличить производительность Zimbra.
В принципе, после создания серверов LDAP, MTA, Proxy, сетевых хранилищ и объединения их в единую инфраструктуру, Zimbra Collaboration Suite на 10000 пользователей готова к вводу в эксплуатацию. Схема работы такой конфигурации будет достаточно простой:
На схеме отображены основные узлы системы и потоки данных, которые будут между ними циркулировать. При такой конфигурации инфраструктура будет совершенно не защищена от потери данных, простоя, связанного с выходом из строя какого-либо из серверов и так далее. Давайте же посмотрим на то, как именно можно защитить свою инфраструктуру от этих проблем.
Основной метод — это аппаратная избыточность. Дополнительные узлы MTA и Proxy могут в случае выхода из строя главных серверов, временно взять на себя роль основных. Дублирование узлов критически важной инфраструктуры практически всегда является отличной идеей, но не всегда она реализуема в желаемом объеме. Яркий пример — резервирование серверов, на которых хранится почта. В настоящее время Zimbra Collaboration Suite Open-Source Edition не поддерживает создание дублирующих хранилищ, поэтому в случае отказа одного из таких серверов избежать простоя не получится, и для снижения времени простоя, вызванного отказом почтового хранилища, ИТ-менеджер может развернуть его резервную копию на другом сервере.
Так как встроенной системы резервного копирования в Zimbra OSE нет, то нам понадобится Zextras Backup, поддерживающий резервирование в реальном времени, и внешнее хранилище. Поскольку Zextras Backup, осуществляя снятие полных и инкрементальных резервных копий, складывает все данные в папку /opt/zimbra/backup, было бы разумным подмонтировать в нее внешнее, сетевое или даже облачное хранилище, чтобы в случае падения одного из серверов иметь на руках носитель с актуальной на момент ЧП резервной копией. Развернуть ее можно как на резервном физическом сервере, так и на виртуальной машине и в облаке. Неплохой идеей также будет установить MTA со спам-фильтром перед сервером с Zimbra Proxy, чтобы снизить количество поступающего на сервер мусорного трафика.
В итоге защищенная инфраструктура Zimbra будет выглядеть примерно так:
При такой конфигурации инфраструктура Zimbra не только сможет обеспечить предоставление качественных услуг 10.000 пользователям, но и в случае возникновения нештатной ситуации позволит максимально быстро устранить ее последствия.