SnapCreator вблизи. Часть 1.
Вот уже несколько лет, как среди программных продуктов NetApp есть такая штука, как SnapCreator. К сожалению, как я обратил внимание, он не только очень плохо известен пользователям, но даже те, кто знает про него, используют его крайне редко. А ведь это штука, которая, благодаря своей гибкости, может решить многие задачи, связанные с защитой данных на системе хранения и в прикладных системах, ее использующих.
SnapCreator первоначально был разработан в 2007 году как “служебный”, внутренний продукт, внутри подразделения Professional Services и Rapid Responce Engineering Group, для того, чтобы облегчить построение систем защиты данных в снэпшоты системы хранения для пользовательских прикладных систем, не входящих в список поддерживаемых “официальным” продуктом NetApp - SnapManager.
То есть, если у вас используется MS SQL Server, MS Exchange, Sharepoint, Oracle, SAP, Hyper-V или vSphere (и у вас есть деньги на лицензию SnapManager), то все относительно просто. Вы устанавливаете SnapManager для соответствующего программного продукта, и дальше он делает все сам.
Зачем нужен SnapManager, и почему нельзя обойтись просто командой snap create из консоли, или переданной через ssh или rsh? Ну, например потому, что некоторые программы требуют некоей согласованной последовательности действий на своей стороне, чтобы состояние данных, записанных на дисках системы хранения, было корректным, или еще говорят “консистентным”. Ведь, например, какие-то данные могут оказаться в буферах кэша сервера, как на стороне программы, так и файловой системы, базы SQL могут иметь незавершенные транзакции, и так далее. Все это требует, чтобы перед тем, как будет сделан “снимок”, снэпшот состояния данных, эти данные на дисках уже находились какое-то время в некоем стабильном, непротиворечивом состоянии, то есть все равно нужен некий “агент” на стороне программного продукта, умеющий с ним взаимодействовать.
Таким образом, если у вас используется какой-нибудь MySQL, Sybase, Xen, KVM или что-то подобное, вам нельзя так просто взять и сделать снэпшот. Нужно написать какую-то систему-посредник, между вашим софтом, и софтом Data ONTAP. Вот для того, чтобы облегчить такую задачу для специалистов Professional Services и был написан SnapCreator.
SnapCreator - это платформа, или, иначе говоря, фреймворк, для написания скриптов и агентов, взаимодействующих с вашей прикладной программной системой, с системой хранения, обеспечивающий автоматизацию взятия корректных, консистентных снэпшотов для данных этой программной системы. Вначале, первые несколько своих версий, это была закрытая внутренняя разработка, начиная с версии 3 она стала ограниченно доступна всем желающим. В настоящий момент для скачивания и использования доступна уже версия 4.1
Официально в настоящее время существуют две линейки, официальная, и так называемая Community Edition. Последняя это, так сказать, unstable, developers edition, где обкатываются все мульки, которые потом деплоятся в официальную поддерживаемую компанией ветку.
Архитектурно SnapCreator является клмент-серверным приложением. Существует так называемый SnapCreator Server, выполняющий код компонента Workflow Engine, который многопоточно обрабатывает поступающие от Агентов и собственного GUI и/или CLI запросы. Так как API открыт, то использовать SnapCreator могут любые внешние системы, например это могут быть коммандлеты PowerShell, другие продукты NetApp, такие как Unified Manager (для него есть свой собственный API), и даже собственные самописанные системы клиентов.
“Другим концом” Snap Creator Server взаимодействует с внутренним API Data ONTAP, обеспечивая все нужные вызовы и отдачу команд.
Конфигурации, jobs, и метаданные плагинов хранятся в специальной структуре - Репозитории (Repository / Extended Repository). Расписания задач, сами задачи (jobs), пользователи и их права доступа (RBAC) хранятся в базе данных (Database).
Наконец, специальный API есть для “клиентов”, агентов SnapCreator.
Посмотрим теперь подробнее на систему SnapCreator со стороны Агента.
Агент - это программный продукт, написанный на Java, чтобы многопоточно выполняться на всех поддерживаемых OS. В ранних версиях в качестве транспорта использовался обычный HTTP, начиная с версии 4.1 взаимодействие Агента и Сервера полностью шифруется в HTTPS.
Основным компонентом, ядром SC Agent является Operation/Execution Manager.
Ядро выполняет запросы от плагинов, которые могут быть как нативными на Джава, так и поддерживаться ранее написанные плагины “не-Java” (значительное их количество для разных программных систем было написано для версий SC 3.6 и 4.0, существовавших ранее), в том числе и на разных скриптовых языках, Perl, PowerShell, даже на UNIX Shell.
В следующих постах разберем то, как пишутся собственно плагины для SnapCreator.
