Помимо совершенно новых сервисов, вроде Zextras Docs и Zextras Team, о которых мы уже рассказывали ранее, в Zextras Suite 3.0 были значительно улучшены и уже привычные пользователям расширения для Zimbra Collaboration Suite Open-Source Edition. Наиболее значительной переработке подверглось расширение Zextras Backup, которое используется для создания резервных копий почтовых ящиков и, благодаря поддержке транзакционного резервирования, позволяет делать это в режиме реального времени, а также снизить размер резервной копии за счет эффективного сжатия данных. Zextras Backup в новой версии Zextras Suite позволяет добиться 30% прироста производительности при резервном копировании, а также позволяет системному администратору настроить желаемый уровень сжатия данных и настроить число потоков. Чтобы подробнее узнать о том, какие премущества эти новшества могут дать системному администратору, а также о том, каким образом был достигнут подобный прирост, мы решили поговорить с главным архитектором компании Zextras Luca Arcara.
Как рассказал нам Luca, данные изменения стали возможными благодаря использованию нового внутреннего планировщика, который способен дедуплицировать и распараллеливать операции резервного копирования, а также новой библиотеке JSON. Также важным нововведением стала возможность настроить количество потоков, которые будут использоваться при сканировании изменений, происходящих в учетных записях, что позволяет системному администратору использовать все преимущества многоядерных процессоров.
В связи с этим, сам собой напрашивается вопрос — можно ли добиться дополнительного прироста производительности за счет использования более мощного железа и, в частности, более многоядерных процессоров? Как оказалось, такой трюк не сработает. Дело в том, что на скорость работы резервирования в реальном времени в большей степени влияет время выполнения операций ввода-вывода, а также количество выполняемых операций в единицу времени, нежели производительность оперативной памяти или центрального процессора.
Именно поэтому, если речь идет о сервере с несколькими сотнями почтовыми ящиками, использовать какое-то дополнительное оборудование на нем необязательно. Однако, если вам действительно важно добиться максимальной производительности, то для вас подойдет сервер с двухъядерным процессором, 2-4 гигабайтами оперативной памяти и, что самое важное, выделенным SSD для хранения метаданных резервного копирования. Но если ваша инфраструктура обсчитывает миллионы различных изменений, например 1000 почтовых ящиков с квотой в 10 гигабайтов каждый, то лучше всего для вас будет перейти на использование такой файловой системы, как XFS, поддерживающей миллиарды айнодов для хранения данных. Также рекомендуется увеличить размер блоков в устройствах для хранения метаданных резервного копирования и архива резервных копий для того, чтобы максимально ускорить процесс сканирования структуры каталогов. Иными словами, системному администратору следует уменьшить размер блока в хранилище для метаданных, поскольку они обычно занимают меньше 4 килобайтов, составляющих обычный блок файловой системы ext4, и увеличить размер блока в хранилище для BLOB-объектов, так как они обычно занимают больше 4 килобайтов.
Также в Zextras 3.0 появилась возможность настроить уровень сжатия данных резервного копирования. Если раньше в Zextras Backup уровень сжатия был установлен на отметке 3 и изменить его было нельзя, то теперь системный администратор может самостоятельно установить степень сжатия от 0 до 9. Как оказалось, появилась эта функция неспроста.
Поскольку Zextras Suite использует открытые стандарты, компрессия в Zextras Backup осуществляется при помощи GZip и только для BLOB-объектов, содержащих данные непосредственно из писем. Внимательный читатель тут же заметит небольшое несоответствие, ведь уровень сжатия по умолчанию в GZip составляет 6, а в Zextas Suite он равен 3. Уровень сжатия по умолчанию специально был понижен, чтобы снизить нагрузку на центральный процессор и обеспечить большую отзывчивость высоконагруженных систем, обеспечивая при этом приемлемый уровень сжатия.
Количество места, которое сможет сэкономить системный администратор, зависит от того, какие данные хранятся на его сервере. Например, при хранении же сжатых вложений в форматах JPG, PDF или других, пользователь Zextras Backup не получит особого преимущества от повышения уровня сжатия. Однако, если он хранит много текстовых или HTML-сообщений электронной почты, документов, электронных таблиц или простых текстовых файлов, более высокая степень сжатия поможет сэкономить больше места. Поскольку BLOB-объекты — это файл BASE64 EML, сжатие может уменьшить занимаемый ими объем до 65%.
Именно поэтому, перед выставлением определенного коэффициента сжатия системному администратору следует оценить структуру хранимых файлов и в том случае, если среди них будут преобладать несжимаемые JPEG или PDF, снизить коэффициент сжатия до минимума, обеспечив максимальную производительность сервера, либо, если большая часть хранимой информации представляет из себя текстовые документы и таблицы, повысить уровень сжатия, чтобы обеспечить максимальную экономическую эффективность своего сервера.
Наилучшим же вариантом станет тестирование — экспорт резервной копии из продакшена в тестовую среду с различными степенями сжатия. Такое тестирование наглядно покажет то, как степень сжатия влияет на загрузку центрального процессора, а также то, как влияет на занимаемое резервной копией дисковое пространство.
Таким образом, обновленное расширение Zextras Backup позволяет системному администратору значительно ускорить создание резервных копий, а значит не допустить потерь данных в случае форс-мажорных ситуаций, а в отдельных случаях повысить эффективность хранения резервных копий за счет сжатия бэкапов.
По всем вопросам, связанными c Zextras Suite вы можете обратиться к Представителю компании «Zextras» Екатерине Триандафилиди по электронной почте ekaterina.triandafilidi@zextras.com
Как рассказал нам Luca, данные изменения стали возможными благодаря использованию нового внутреннего планировщика, который способен дедуплицировать и распараллеливать операции резервного копирования, а также новой библиотеке JSON. Также важным нововведением стала возможность настроить количество потоков, которые будут использоваться при сканировании изменений, происходящих в учетных записях, что позволяет системному администратору использовать все преимущества многоядерных процессоров.
«Новый планировщик мгновенно получает уведомления о каждом изменении из почтового ящика и ставит его в очередь в сверхлегкой структуре памяти, где операция дедуплицируется и планируется, чтобы оптимизировать сквозную передачу резервируемых данных. Кроме того, мы проанализировали и улучшили библиотеку JSON. Теперь она работает быстрее предыдущей версии, и оптимизирует использование процессора и памяти, уменьшая количество обращений к сборщику мусора» — рассказывает Luca Arcara.
В связи с этим, сам собой напрашивается вопрос — можно ли добиться дополнительного прироста производительности за счет использования более мощного железа и, в частности, более многоядерных процессоров? Как оказалось, такой трюк не сработает. Дело в том, что на скорость работы резервирования в реальном времени в большей степени влияет время выполнения операций ввода-вывода, а также количество выполняемых операций в единицу времени, нежели производительность оперативной памяти или центрального процессора.
Именно поэтому, если речь идет о сервере с несколькими сотнями почтовыми ящиками, использовать какое-то дополнительное оборудование на нем необязательно. Однако, если вам действительно важно добиться максимальной производительности, то для вас подойдет сервер с двухъядерным процессором, 2-4 гигабайтами оперативной памяти и, что самое важное, выделенным SSD для хранения метаданных резервного копирования. Но если ваша инфраструктура обсчитывает миллионы различных изменений, например 1000 почтовых ящиков с квотой в 10 гигабайтов каждый, то лучше всего для вас будет перейти на использование такой файловой системы, как XFS, поддерживающей миллиарды айнодов для хранения данных. Также рекомендуется увеличить размер блоков в устройствах для хранения метаданных резервного копирования и архива резервных копий для того, чтобы максимально ускорить процесс сканирования структуры каталогов. Иными словами, системному администратору следует уменьшить размер блока в хранилище для метаданных, поскольку они обычно занимают меньше 4 килобайтов, составляющих обычный блок файловой системы ext4, и увеличить размер блока в хранилище для BLOB-объектов, так как они обычно занимают больше 4 килобайтов.
Также в Zextras 3.0 появилась возможность настроить уровень сжатия данных резервного копирования. Если раньше в Zextras Backup уровень сжатия был установлен на отметке 3 и изменить его было нельзя, то теперь системный администратор может самостоятельно установить степень сжатия от 0 до 9. Как оказалось, появилась эта функция неспроста.
«Идея функции выбора уровня сжатия при резервном копировании родилась во время общения с нашими клиентами, которые использовали для хранения резервных копий специализированные устройства хранения, которые поддерживают дедупликацию и сжатие на уровне блоков. Помимо того, что сжатые файлы гораздо труднее дедуплицировать, двойное сжатие при определенных обстоятельствах приводило к увеличению итогового размера файлов. Теперь же обладатели таких устройств могут понизить уровень сжатия или вовсе отключить его для того, чтобы добиться оптимального использования своих устройств и снизить нагрузку на центральный процессор» — поделился с нами Luca Arcara.
Поскольку Zextras Suite использует открытые стандарты, компрессия в Zextras Backup осуществляется при помощи GZip и только для BLOB-объектов, содержащих данные непосредственно из писем. Внимательный читатель тут же заметит небольшое несоответствие, ведь уровень сжатия по умолчанию в GZip составляет 6, а в Zextas Suite он равен 3. Уровень сжатия по умолчанию специально был понижен, чтобы снизить нагрузку на центральный процессор и обеспечить большую отзывчивость высоконагруженных систем, обеспечивая при этом приемлемый уровень сжатия.
Количество места, которое сможет сэкономить системный администратор, зависит от того, какие данные хранятся на его сервере. Например, при хранении же сжатых вложений в форматах JPG, PDF или других, пользователь Zextras Backup не получит особого преимущества от повышения уровня сжатия. Однако, если он хранит много текстовых или HTML-сообщений электронной почты, документов, электронных таблиц или простых текстовых файлов, более высокая степень сжатия поможет сэкономить больше места. Поскольку BLOB-объекты — это файл BASE64 EML, сжатие может уменьшить занимаемый ими объем до 65%.
Именно поэтому, перед выставлением определенного коэффициента сжатия системному администратору следует оценить структуру хранимых файлов и в том случае, если среди них будут преобладать несжимаемые JPEG или PDF, снизить коэффициент сжатия до минимума, обеспечив максимальную производительность сервера, либо, если большая часть хранимой информации представляет из себя текстовые документы и таблицы, повысить уровень сжатия, чтобы обеспечить максимальную экономическую эффективность своего сервера.
Наилучшим же вариантом станет тестирование — экспорт резервной копии из продакшена в тестовую среду с различными степенями сжатия. Такое тестирование наглядно покажет то, как степень сжатия влияет на загрузку центрального процессора, а также то, как влияет на занимаемое резервной копией дисковое пространство.
Таким образом, обновленное расширение Zextras Backup позволяет системному администратору значительно ускорить создание резервных копий, а значит не допустить потерь данных в случае форс-мажорных ситуаций, а в отдельных случаях повысить эффективность хранения резервных копий за счет сжатия бэкапов.
По всем вопросам, связанными c Zextras Suite вы можете обратиться к Представителю компании «Zextras» Екатерине Триандафилиди по электронной почте ekaterina.triandafilidi@zextras.com
