При развертывании почтового сервера Carbonio в формате On-Premise, системному администратору приходится решать вопрос хранения данных - главной ценности информационных систем. Для почтовых систем именно хранилище данных является ключевой составляющей, обеспечивающей отзывчивость и стабильную работу сервиса. Однако не бывает таких хранилищ, которые были бы одновременно быстрыми, надежными и недорогими. Обычно администратору приходится выбирать два, а иногда и один из этих параметров. В данной статье мы расскажем о том, по какому принципу следует выбирать хранилища для почтового сервера Carbonio.
Все примерно представляют, как работают хранилища данных. Множество ячеек, способных хранить электрический заряд, выстраиваются в цепочки битов, которые затем делятся на блоки, доступные для чтения хранящейся в них информации. Отличия между устройствами хранения появляются тогда, когда появляется необходимость предоставить пользователю доступ к данным. Всего выделяется три типа хранилищ в соответствии со слоем абстракции:
Блочное хранилище
Работа идет напрямую с блоками хранилища данных. Все данные находятся в блоках одинакового размера с уникальными идентификаторами, из которых после запроса со стороны клиента формируется ответ на его запрос. Плюсом таких хранилищ являются маленькая задержка и возможность быстрого осуществления операций ввода‑вывода
Файловое хранилище
Работа идет с файловой системой — программной прослойкой, позволяющей структурировать данные на устройстве и осуществлять к ним доступ. Все хранящиеся в нем данные разбиты на файлы, доступ к которым осуществляется по пути из имени сервера и директорий. Такие хранилища наиболее дешевы, но наименее надежны
Объектное хранилище
Работа идет с API — еще одной программной прослойкой, которая обеспечивает доступ к неструктурированными данными, хранящимися в плоской структуре по протоколу HTTP. Это позволяет добиться доступности хранимых данных из любой точки земного шара, а также обеспечить возможность резервирования данных, в том числе географически разнося хранилища. Именно поэтому многие провайдеры предоставляют доступ к объектным хранилищам как услугу
В настоящее время блочные устройства хранения данных не применяются для хранения электронной почты, поэтому рассматривать мы будем только файловые и объектные хранилища.
Главными факторами при подборе хранилища являются объем данных, их структура и связанные с их потерей риски. Как уже говорилось, главное преимущество файловых устройств хранения в их дешевизне и в простоте управления ими. Поскольку все данные представлены в них в виде простых и понятных файлов и каталогов, ими гораздо проще управлять, но и рисков при использовании таких хранилищ значительно больше. К примеру в случае если произойдет аварийное завершение работы, данные на файловом накопителе могут быть повреждены. Но если даже они не пострадают, то проверка целостности файловой системы может занять значительное время.
Поскольку строительство отказоустойчивого объектного хранилища с географически разнесенными накопителями и гарантированной скоростью доступа стоит очень дорого, его обычно приобретают как услугу у провайдера, который уже построил хранилище с соответствующими характеристиками.
Таким образом использование дискового хранилища подразумевает разовую трату на приобретение устройства, а использование объектного хранилища предполагает постоянную оплату услуг провайдера без капитальных вложений. При этом объектное хранилище может гарантировать постоянную доступность файлов.
Сценарии использования
В коммерческой версии Carbonio для хранения данных используются три тома: первичный, вторичный и индексный. В первичном хранятся все наиболее свежие данные, такие как недавние письма, контакты, события календаря, вложения и документы. Во вторичное хранилище данные попадают после заданного администратором срока нахождения на первичном хранилище. В индексном хранилище находятся данные, используемые Apache Lucene. Все три тома могут располагаться на файловых хранилищах, подключение объектных хранилищ допустимо только в случае первичного и вторичного тома для хранения данных. Это приводит к нескольким сценариям использования.
Первичный и вторичный тома на дисковом хранилище.
В этом случае сохранность данных обеспечивается только средствами Carbonio Backup. Транзакционное резервирование данных позволяет формировать резервные копии в режиме реального времени и надежно защищает от отказа дискового устройства, однако процесс восстановления Carbonio из резервной копии — достаточно длительный процесс, который в случае большого количества данных подразумевает простой почтовой системы. Именно поэтому данный сценарий можно рекомендовать только небольшим предприятиям с малым количеством сотрудников. Экономический эффект от использования файловых хранилищ вместо объектных легко перекроет потери от простоя предприятия в случае выхода из строя почтового сервера.
Первичный том на дисковом и вторичный том на объектном хранилище.
Главным плюсом такого сценария является то, что все наиболее востребованные данные будут находиться на дисковом устройстве, которое обладает гарантированной скоростью передачи данных и не зависят от скорость интернет‑соединения. Благодаря этому размер резервной копии, которую необходимо восстанавливать в случае отказа почтовой системы, сильно сокращается из‑за того, что восстанавливать нужно только данные на первичном томе. И даже если на предприятии работают тысячи сотрудников, последствия отказа почтовой системы можно ликвидировать в несколько раз быстрее по сравнению с первым сценарием.
Поскольку во вторичном томе хранятся старые данные, обращения со стороны пользователей к ним будут происходить довольно редко. Это позволяет использовать для их хранения «холодные» или даже «ледяные» объектные хранилища, которые отличаются от обычных типом используемых накопителей, скоростью доступа и более низкими ценами. Это также позволит значительно сэкономить, гарантируя при этом доступность данных.
Первичный том на объектном и вторичный том на дисковом хранилище.
Этот сценарий позволяет обезопасить наиболее актуальные данные почтовой системы, разместив их в объектном хранилище, в то время как более старые данные будут доступны на локальном хранилище. Благодаря этому в случае отказа почтового сервера время восстановления его работоспособности значительно снижается. Фактически этот процесс сводится к установке Carbonio на новый сервер или введению в строй резервного почтового сервера, и восстановлению настроек доменов, учетных записей и классов обслуживания из резервной копии. После этого пользователям будут доступны все недавние данные, а администратор сможет приступить к восстановлению данных со вторичного тома, если он пострадал при отказе.
Данный сценарий является более затратным по сравнению со вторым за счет того, что для хранения более свежих данных может использоваться только более быстрое и дорогое «горячее» хранилище. Соответственно подойдет он только тем предприятиям, которые готовы смириться с непродолжительным отказом почтового сервера и строгими правилами по срокам ввода его в строй.
Первичный и вторичный тома на объектном хранилище.
Размещение обоих томов данных на объектном хранилище гарантирует сохранность всех данных почтовой системы и добиться полной отказоустойчивости почтового сервера.
Этот сценарий не дает особых преимуществ по времени ввода упавшего сервера в эксплуатацию, однако позволяет в тот же срок вернуть доступ не только к самым свежим данным, но и к архивным письмам.
Использование объектного хранилища для хранения всех данных почтового сервера также дает возможность создать централизованное хранилище — единые первичный и вторичный тома для всех почтовых хранилищ в системе, что позволяет сохранять данные доступными для пользователей даже в случае отказа одного или нескольких хранилищ и за счет этого сократить время простоя в случае аварий до нуля.
Такой сценарий является наиболее затратным с экономической точки зрения и подходит для крупных предприятий, где многие бизнес‑процессы завязаны на электронную почту.
Таким образом Carbonio является достаточно гибким в плане использования различных хранилищ данных, и используемые в нем типы хранилища влияют не только на отзывчивость сервиса, но также и на уровень его доступности и безопасность данных.
По вопросам тестирования, приобретения, предоставления лицензии и консультаций обращаться на почту sales@svzcloud.ru к эксклюзивному партнеру Zextras.
M_AJ
Вот эту фразу вообще не понял. Жесткий диск и SSD – блочные устройства.
Pas
Я так понимаю, что автор имел в виду что-то типа hash-нарезки файлов/диркторий на файловой системе.
Zextras Автор
Добрый день, спасибо за комментарий. Имелись ввиду файловые хранилища, как слой абстракции над блочными хранилищами типа SAN