Группировка архива Kerio Connect

Так исторически сложилось, что в нашей компании в качестве почтового сервера используется Kerio Connect.

И так же исторически сложилось, что стоит он на Виндах.

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

Обязательно отдельным постом опишу интеграцию с AD и автоматизацию сего счастья с помощью моего любимого Powershell.

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

И я обнаружил вот что:

Оказывается архив сохранялся в отдельные папки для каждого дня. Это создало очевидные проблемы в поиске писем.

Я обратился в Т.П. Kerio за помощью, возможно они реализовали этот функционал, но увы...пришлось писать скрипты.

1. Первое и самое главное понадобится программка Bulk Rename Utility в консольном варианте

2.Второе - скрипт для переименования всех файлов, лично  я писал на cmd:

chcp 1251

setlocal enabledelayedexpansion

set input=d:\arch

set output=d:\test

d:

for /f %%i in ('dir /b %input%\') do (

cd %input%\%%i\#msgs

for /f %%j in ('dir /b %input%\%%i\#msgs\') do (

ren %%j %%i_%%j

)

set h=%%i

IF NOT EXIST "%output%\!h:~0,4!\!h:~0,8!\#msgs" ( mkdir %output%\!h:~0,4!\!h:~0,8!\#msgs )

move %input%\%%i\#msgs\* %output%\!h:~0,4!\!h:~0,8!\#msgs\

)

for /f %%k in ('dir /b %output%\') do (

for /f %%l in ('dir /b %output%\%%k') do (

IF NOT EXIST %output%\%%k\%%l\#assoc ( mkdir %output%\%%k\%%l\#assoc )

IF NOT EXIST %output%\%%k\%%l\index.fld ( type NUL > %output%\%%k\%%l\index.fld )

IF NOT EXIST %output%\%%k\%%l\properties.fld ( type NUL > %output%\%%k\%%l\properties.fld )

IF NOT EXIST %output%\%%k\%%l\status.fld (  type NUL > %output%\%%k\%%l\status.fld )

D:\test\BRC_Unicode_64\BRC64.exe /DIR:%output%\%%k\%%l\#msgs /SORTBY:n /REMOVENAME /AUTONUMBER:1:1:S::12:8 /EXECUTE

)

) 

Отказоустойчивая инфраструктура на базе Microsoft Hyper-V 2012

Отказоустойчивая инфраструктура на базе Microsoft Hyper-V 2012

Основные критерии:

1.Распределение нагрузки и обеспечение масштабируемости предоставляемых сервисов

2.Резервирование на программном и железном уровне максимальное кол-во узлов

3.Доступность инфраструктуры 24х7

4.Время восстановления инфраструктуры в случае падения в течении 3х часов.

Сформированные серверы:

1. Контроллер домена, DNS
2. Почтовый сервер на Kerio Connect
3. Терминальный сервер 1С via RDP
4. Сервер баз данных 1С MS SQL
5. Сервер CRM Bitrix

Решение:

1.Поскольку практически вся инфраструктура построена на базе продуктов Microsoft, то решено использовать Hyper-V 2012 в качестве гипервизора для разнесения служб по отдельным виртуальным машинам

2.Для резервирования на железном уровне:

• Использовать существующий сервер HP DL120 G6 в качестве файлового хранилища
• Использовать существующий сервер HP DL360 G7 в качестве резервного гипервизора
• Использовать новый сервер Supermicro 1027R-N3RF в качестве основного гипервизора

С точки зрения отказоустойчивости встал выбор между тремя вариантами обеспечения резервирования:

Первый вариант: 

Обеспечить холодный бэкап используемых VM

• С помощью VSS снимать каждый час снимок VM с 8:00 до 19:00 и хранить 5 дней.
• Делать полную копию VM с основного на резервный гипервизор и хранить в выключенном состоянии 

Второй вариант:

Обеспечить избыточность VM, создав на резервном гипервизоре:

• вторичный контроллер домена
• резервный почтовый сервер с синхронизацией каталогов раз в 30 минут
• суточную копию терминального сервера 
• вторичный сервер баз данных MS SQL с репликацией
• вторичный сервер CRM с синхронизацией веб-данных rsync и репликацией MySQL

Третий вариант:

Обеспечить полное дублирование данных используя Hyper-V Clustering на SMB 3.0

В данный момент провожу анализ обоих методов, после описания плана восстановления в случае сбоя при использование этих трех методов и сроков внедрения напишу результаты.