Для чего настраивается cdp криптопро
CDP: как выбрать и внедрить
Фактически, это продвинутая база данных, где по каждому клиенту собираются данные (транзакционные, поведенческие, демографические) из множества источников (как онлайн, так и офлайн). Платформа создает универсальные профили клиентов, содержащие все необходимые атрибуты и признаки, и хранит их.
Так получается 360-градусный портрет, или профиль, клиента. Профили клиентов используются для построения сегментаций и аналитики, отправки маркетинговых кампаний и анализа их эффективности, а также всевозможных экспериментов для увеличения эффективности бизнеса.
Маркетинг: нужен человек, который понимает принципы CRM-маркетинга и может предложить сценарии использования CDP под конкретный бизнес
IT: потребуется поддержка на этапе внедрения CDP и помощь в управлении такими задачами, как настройка веб-хуков, веб-рекомендаций, интеграций. Знание HTML, CSS и Javascript также полезно для создания эффективных weblayer’ов.
CDP нужен компаниям, у которых есть большие данные о клиенте, например:
CDP внедрять рано или вообще не надо:
1. Определяем, какие задачи будет решать CDP. Просто ответьте сами себе максимально подробно на 3 вопроса: 1) Как вы планируете использовать CDP? 2) Нужна ли вам CDP с возможностью управления кампаниями и персонализацией (CDXP)? 3) Или достаточно консолидации клиентских данных из различных источников и сегментации (автономная CDP)?
2. Пишем “хотелки”, например:
3. Подбираем несколько CDP в соответствии с требованиями. Приведу для примера наиболее известный на Западе ресурс со сравнением компаний для различных IT и маркетинг задач G2Crowd, в котором представлены различные CDP-платформы по ссылке.
4. Оцениваем выбранные CDP по:
5. В шорт-листе оставляем 3 кандидата.
6. Оцениваем кандидатов из шорт-листа. Попросите показать, как они работают в контексте ваших сценариев. Как вариант, запросите RFP или пилотный проект, который поможет убедиться, что выбранное решение действительно соответствует вашим потребностям.
Если для выбора CDP, описанного выше, необходимо 1-2 месяца в зависимости от внутренних процессов компании, то для внедрения нужно 2-3 месяца. Конкретный срок зависит от:
сложности интеграции — с каким набором инструментов нужна интеграция?
требований к результатам — чего вы хотите от CDP?
текущего состояния данных — очищение данных может привести к более длительной интеграции
уникальных особенностей бизнеса
уровня детализации в атрибутах данных.
Вот примерная схема внедрения CDP-платформы:
Павел, спасибо за статью.
Чем CDP принципиально отличается от BI систем? Не хейта ради, правда интересно
Я не Павел, но как понимаю, в BI-системах можно только анализировать кампании, но не создавать их.
Всегда интересно узнавать новое и использовать это в своей борьбе с конкурентами.
Как я настраивал новые утилиты по работе с электронной подписью в Linux
Поговорим немного про средства электронной подписи (ЭП) с использованием отечественных ГОСТ-алгоритмов в Linux. Несмотря на то, что различные средства и интерфейсы по работе с ЭП в Linux развиты даже лучше, чем в Windows, использовать их не так просто.
Такое положение вещей сохранялось последние несколько лет. Но с конца 2016 года ситуация изменилась в лучшую сторону. Появилось сразу два продукта, которые позволяют работать с электронной подписью по стандарту ГОСТ и шифрованием без использования консоли – это Rosa Crypto Tool и Trusted eSign. Оба эти продукта для работы с криптографией используют «КриптоПро CSP» для Linux. Поэтому, перед тем как обратиться к описанию самих продуктов, поговорим немного про «КриптоПро CSP».
«КриптоПро CSP» под Linux — неоднозначный продукт. С одной стороны, это одно из самых распространенных и мощных сертифицированных средств по работе с криптографией как в Windows, так и в Linux. С другой стороны, для простого человека пользоватся его интерфейсами даже в Windows не так-то просто. А в Linux доступен только консольный интерфейс. Надеюсь, что компания «КриптоПро» в курсе этой ситуации, и в будущем нас ждут новые красивые и удобные интерфейсы, как для Windows, так и для Linux.
Для настройки нам понадобится:
Настройка «КриптоПро» CSP
Несмотря на то, что есть несколько неплохих статей по настройке «КриптоПро CSP» под Linux (например, тут или тут), я опишу здесь свой вариант. Основная причина в том, что большинство инструкций написаны для «Крипто Про CSP» версии 3.x. А современная версия «КриптоПро CSP» 4.0 не является 100% совместимой с 3.x. Дополнительная причина – всегда приятно иметь полную инструкцию по настройке в одном месте, а не переключаться с одного окна на другое.
Приступаем к настройке.
Скачиваем «КриптоПро CSP» для Linux с официального сайта КриптоПро — www.cryptopro.ru/downloads
Распаковываем «КриптоПро CSP» для Linux:
Далее у нас есть 2 варианта – автоматическая установка и установка вручную. Автоматическая установка запускается командой:
Здесь надо отдать должное разработчикам «КриптоПро» – автоматическая установка для большинства дистрибутивов отрабатывает успешно. Хотя бывают и нюансы. Например, если у вас не хватает некоторых пакетов, то установка будет успешно завершена, хотя некоторый функционал работать не будет.
Если что-то пошло не так, или вы по тем или иным причинам хотите использовать установку в ручном режиме, то вам необходимо выполнить:
Устанавливаем лицензию для «КриптоПро CSP» для Linux и проверяем, что все работает нормально:
Мы должны получить что-то вроде:
Настройка работы с Рутокен ЭЦП 2.0
Для работы с токенами в ОС Linux есть масса различных средств и драйверов. Для описания всех этих средств понадобится отдельная статья. Поэтому я не буду подробно описывать, как это работает, и почему нам нужны именно эти пакеты.
Устанавливаем пакеты для работы с Рутокен ЭЦП 2.0:
Нам также необходимо установить пакеты КриптоПро CSP для поддержки работы с токенами:
Получаем тестовый сертификат
Перед тем как перейти непосредственно к работе с подписью, надо сгенерировать ключевую пару и создать сертификат электронной подписи. Если у вас уже есть Рутокен с контейнером «КриптоПро», то эту часть можно смело пропустить.
Воспользуемся тестовым УЦ компании «КриптоПро» по адресу — https://www.cryptopro.ru/certsrv/
Создаем запрос на сертификат с параметрами по умолчанию.
Проверим, что сертификат получен успешно.
Чтобы убедиться, что «КриптоПро CSP» успешно увидел токен, выполним:
Мы должны получить что-то вроде:
Теперь проверяем, что сертификат на токене видится успешно:
Записываем в хранилище сертификатов КриптоПро информацию об этом сертификате:
Проверим, что сертификат успешно сохранился в хранилище:
На этом основная настройка завершена, и мы можем начинать подписывать или шифровать файлы с использованием различных средств. Переходим к тому, зачем задумывалась эта статья.
Подпись средствами «КриптоПро CSP»
В составе «КриптоПро CSP» есть утилита csptestf, позволяющая выполнять различные криптографические операции. Как я уже писал выше, у этой утилиты есть 2 недостатка:
Здесь,
my — параметр, в котором надо указать часть Common Name сертификата для подписи;
detached — позволяет создать открепленную подпись;
alg GOST94_256 — задает алгоритм хэширования, который будет использоваться при создании подписи.
Более подробную информацию о возможных параметрах вы можете получить, выполнив команду:
Такой интерфейс отлично подходит для подготовленного пользователя или для автоматизации операций в скриптах.
Поговорим теперь об утилитах, которые облегчают жизнь обычным пользователям при работе с подписью и шифрованием в Linux.
Rosa Crypto Tool
Как следует из названия, это утилита для работы с электронной подписью и шифрованием для дистрибутива ROSA Linux. В данный момент утилита доступна в репозиториях Rosa Linux и Alt Linux.
Эта утилита разрабатывается одним человеком – Михаилом Вознесенским. У нее простой, но удобный интерфейс. На данный момент утилита находится в активной разработке – с ноября 2016 года мне удалось протестировать три версии. Последняя версия, доступная на момент написание статьи — 0.2.2. Сейчас утилита поддерживает работу только с «КриптоПро CSP» для Linux, однако в ближайшее время будет добавлена поддержка других криптопровайдеров.
Что внутри? Утилита написана на Python с использованием PyQt4 для графического интерфейса.
Установить ее можно, использовав «Управление программами» в Rosa Linux.
Вставляем токен и запускаем утилиту.
Видим, что токен определился успешно и был найден наш сертификат.
Интерфейс программы настолько прост, что описывать и показывать в статье все его функции не имеет смысла. Попробуем только подписать файл.
Выбираем файл и жмем “Подписать файл”. Получаем вот такое предупреждение.
Нажимаем «OK» и получаем информацию о том, что файл был подписан успешно.
Основное достоинство этой утилиты в том, что она совершенно бесплатная, в отличии нашего следующего продукта.
По сравнению с использованием «КриптоПро CSP» из консоли:
+ На порядок проще использовать;
— Отсутствуют различные параметры подписи.
Исходный код программы доступен в публичном репозитории на ABF:
abf.io/uxteam/rosa-crypto-tool-devel
Система контроля версий, которую использует «НТЦ ИТ РОСА», интегрирована в сборочную среду и базируется на Git. Можно вполне использовать любой клиент git.
Надеюсь, разработчики других отечественных дистрибутивов Linux, таких как Astra Linux, GosLinux и другие добавят в свои дистрибутивы пакеты с rosa-crypto-tool.
Trusted eSign
Второй продукт, про который мы поговорим, это Trusted eSign от компании “Цифровые технологии”. Она известна на российском рынке ИБ как разработчик средства по работе с подписью и шифрованием для ОС Windows – «КриптоАРМ».
Главное, не путать этот продукт с Trusted.eSign – web-сервисом по работе с подписью этой же компании.
Найти продукт на сайтах компании “Цифровые технологии” непросто. Небольшое описание есть в магазине http://www.cryptoarm.ru/shop/trusted_esign, продукт также можно скачать в разделе «Центр загрузки» на сайте trusted.ru — https://trusted.ru/support/downloads/?product=133
К сожалению, продукт пока доступен только в виде deb пакета для 64-битных систем. С чем связано такое ограничение, непонятно. Будем надеяться, что в ближайшее время компания выпустит и rpm пакет, а также версии для 32-битных дистрибутивов Linux.
Скачиваем с официального сайта deb-пакет и устанавливаем командой:
Запускаем Trusted eSign.
Сразу видно, что разработка не обошлась без дизайнера. Никакого сарказма. Все действия делаются просто и логично, а внешний вид радует глаз. К сожалению, большинство средств и программ в области ИБ от российских разработчиков разработаны без привлечения UX-специалистов и дизайнеров и заставляют своих пользователей страдать и плакать кровавыми слезами. Создается впечатление, что другими средства информационной безопасности просто не могут быть. “Цифровые технологии” опровергают это. Плата за красоту и удобство – необходимость платить за лицензию.
Но вернемся к подписи.
Выбираем раздел “Электронная подпись”:
Выбираем «Сертификат для подписи»:
Выбираем файлы для подписи и жмем «Подписать»:
Что под капотом? Процитирую с сайта: “Приложение создано на современном движке Electron, для вызова криптографических операций применяется библиотека OpenSSL. Совместимо с СКЗИ “КриптоПро CSP 4.0” и поддерживает все криптографические алгоритмы, реализованные в нем.” Для тех, кто ещё не в курсе Electron — это фреймворк для создания десктопных приложений на платформе node.js.
Сравним Trusted eSign с Rosa crypto tool:
+ Более удобный и красивый интерфейс
— Платная лицензия
Резюме
Подведем итог. В конце 2016 – начале 2017 года наметился неплохой прогресс в средствах по работе с электронной подписью под Linux. Информационная безопасность начинает поворачиваться к пользователю лицом, и с каждым годом требуется все меньше действий для такого простого действия, как подписать или зашифровать файл с использованием отечественных алгоритмов.
Хочется дополнительно отметить такое развитие отечественных продуктов, учитывая современный тренд на замену Windows на Linux в государственных и муниципальных организациях. В рамках этого тренда становится актуальным использование средств криптографической защиты информации под Linux. Хорошие и удобные продукты российских разработчиков помогут государственным организациям и структурам нормально работать и выполнять требования по импортозамещению.
Такое развитие не может не радовать, особенно когда это происходит под Linux.
Настройка расширений CDP и AIA в CA1
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
Эту процедуру можно использовать для настройки точки распространения списка отзыва сертификатов (CDP) и параметров доступа к информации о центре сертификации (AIA) в CA1.
Для выполнения этой процедуры необходимо быть членом группы «Администраторы домена».
Настройка расширений CDP и AIA в CA1
В диспетчере серверов щелкните Сервис, а затем выберите Центр сертификации.
В дереве консоли центра сертификации щелкните правой кнопкой мыши Corp-CA1-CAи выберите пункт свойства.
Имя вашего ЦС отличается от имени компьютера CA1, а имя домена отличается от имени в этом примере. Имя ЦС имеет формат домен имякомпьютерацс-CA.
На вкладке расширения установите следующие флажки:
Включить в CRL. Клиенты используют это для поиска расположений разностных CRL
Включать в CDP-расширение выданных сертификатов
На вкладке расширения установите следующие флажки:
Опубликовать CRL по данному адресу
Публикация разностных CRL по адресу
На вкладке расширения выберите включить в AIA выданных сертификатов.
При появлении запроса на перезапуск Active Directory служб сертификатов нажмите кнопку нет. Служба будет перезапущена позже.
Veeam CDP для самых маленьких
Вот об этом мы сегодня и поговорим: что это за магия такая, как она работает и как мы её реализовали в Veeam Backup & Replication v11.
Зачем CDP нужен этому миру
Начинаем по порядку: а какие проблемы может решить CDP и кому он нужен?
CDP удобнее всего сравнивать с асинхронной репликацией стораджей. То есть ваши виртуалочки спокойно работают, а где-то там далеко внизу одно хранилище реплицирует данные на другое, как бы гарантируя вам, что в случае сбоя вы потеряете минимум информации и просто продолжите работать в новом месте.
Так что если снапшоты можно исключить, их надо исключить.
Как работает CDP
Хотелось бы так, но нет. На практике всё несколько сложнее. Давайте разбираться.
Вот так выглядит общая схема работы. Для видавшего виды VBR пользователя здесь знакомо только слово Proxy. И, пожалуй, да, на прокси вся схожесть с классическими схемами работы и заканчивается.
Координатор. Умывальников начальник и мочалок командир. Управляет всеми процессами, отвечает за связь с vCenter, говорит другим компонентам, что делать, и всячески следит, чтобы всё было хорошо. На местах выглядит как Windows сервис. Единственный, кто знает про существование таких вещей, как vCenter и виртуальные машины. Все остальные работают только с дисками. Поэтому всё, что не связано с репликацией контента, делает координатор. Например, создаёт виртуалку на таргете, к которой мы прицепим реплицируемые диски.
Source filter. Та самая штука, которая занимается перехватом IO запросов. Соответственно, работает уже на ESXi. Дабы повысить надёжность и производительность, один инстанс фильтра работает с одним виртуальным диском. Фильтры держат связь с демоном.
Зачем нужна прокладка в виде демона и почему бы фильтру самому не работать с прокси? Это ограничение технологии со стороны VMware, не позволяющее фильтру работать с внешней сетью. То есть фильтр с демоном связь установить может, а с прокси нет. Это называется by design, и ничего с этим не поделаешь. Во всяком случае, сейчас. И напомню: демон не знает ни про какие виртуальные машины. Он работает с потоками данных от дисков. И ничего другого в его мире не существует. Поэтому диски одной машины могут обрабатываться сразу несколькими прокси. Мы, конечно, стараемся отвозить диски одной машины через один прокси, но если она не справляется, то подключится другая. И это нормально!
Source Proxy. Агрегирует в себе всю информацию, полученную от фильтров через демонов. Хранит всё строго в RAM, с возможностью подключения дискового кэша, если оперативка кончилась. По этому очень (ОЧЕНЬ!) требователен к RAM, дисковому кешу и задержкам на сети. Так что только SSD и прочее адекватное железо.
Прокси занимается составлением так называемых микроснапшотов, которые отправляются дальше. Данные перед передачей обязательно дедуплицируются: если в каком-то секторе произошло 100500 перезаписей, то до прокси дойдут все, но с самого прокси будет отправлена только одна последняя. Так же, само собой, всё сжимается и шифруется. На местах прокси представляют собой Windows машины, которые могут взаимозаменять друг друга, переключать нагрузку и так далее.
Target Proxy. Всё то же самое, но в обратном порядке. Принимает трафик от сорсных проксей, расшифровывает, разжимает, отправляет дальше. Так же может быть как физический, так и виртуальный.
Target Daemon. Занимается записью данных на датастор. Полная копия сорсного демона.
Target Filter. В нормальном состоянии находится в выключенном виде. Начинает работать только во время фейловера и фейлбека, но об этом позже.
Таргетные компоненты от сорсных в данном случае отличаются только названием и своим местом в логической схеме. Технически они абсолютно идентичны и могут меняться ролями на ходу. И даже одновременно работать в двух режимах, чтобы одна машина реплицировалась с хоста, а другая на хост. Но я вам ничего такого не говорил и делать не советовал. Также в момент переключения реплики в фейлбек таргеты переключаются на роль сорсов, а в логах появится соответствующая запись.
Немного промежуточных деталей
Сейчас хочется немного отвлечься на разные детали, понимание которых даст нам более полную картину в будущем.
Как мы видим, процессы, связанные с CDP, довольно плотно интегрированы в сам хост. Так что при выполнении многих операций надо быть предельно внимательным. Например, апгрейд/удаление VAIO драйвера происходит строго через maintenance mode. Установка, что хорошо, такого не требует. На случай отсутствия DRS предусмотрена защита, которая не даст запуститься процессу, однако это же IT, и бывает тут всякое. Поэтому действовать надо осторожно и внимательно.
И ловите бонус: фильтр с хоста можно удалить командой:
И дальше по обстановке.
И, конечно же, не забудем обрадовать ненавистников разного рода устанавливаемых на гостевую ОС агентов и сервисов. Для CDP ничего такого делать не надо, и даже админские креды никому больше не нужны (если только вы готовы отказаться от VSS точек с application consistent состоянием). Наконец-то угнетатели повержены и можно спать спокойно. Всё работает исключительно за счёт магии VAIO API.
Retention
На длинной дистанции мы используем Long-term retention, гарантирующий консистентность на уровне приложений(application aware). Делается это с помощью VSS и требует предоставления админской учётки от гостевой ОС. Выглядит это как создание точек отката с определённой периодичностью (например, раз в 12 часов), которые хранятся несколько дней.
Расписание, само собой, гибко настраивается, позволяя, например, обеспечивать crash-consistent только в офисное время, а в ночное переключаться на редкие, но application-consistent точки.
Если подходить глобально, то вариантов сделать фейловер у нас два: прямо сейчас по кнопке Failover now… или создав Failover Plan. Соответственно, если случилась авария, то мы можем сделать фейловер нашей реплики в следующих режимах:
Откат на последнее состояние (crash-consistent)
Восстановиться на нужный нам момент времени в режиме Point-in-time (crash-consistent)
Откатиться на Long term точку (здесь можно выбрать между application-aware и crash-consistent)
А failback и permanent failover делаются по правилам обычных старомодных реплик, так что останавливаться на этом не буду. Всё есть в документации.
Совет: в выборе нужного момента времени при Point-in-time ресторе очень удобно двигать ползунок стрелочками на клавиатуре 😉
Как работает CDP ретеншн
И прежде чем мы начнём обсуждать, почему вы поставили хранить три точки отката, а на диске их двадцать восемь, давайте посмотрим, что вообще будет храниться на таргетной датасторе.
.VMDK Тут без сюрпризов. Обычный диск вашей машины, который создаётся в момент первого запуска репликации.
Short-term retention
Теперь рассмотрим, как это работает.
В первый момент времени на таргете нет ничего, поэтому, чтобы начать работать, нам надо взять и в лоб поблочно скопировать VMDK файл с сорса на таргет.
Совет: если тащить по сети огромный VMDK вам нет никакого удовольствия, то Seeding и Mapping вам в помощь. Они позволяют перевести ваши файлы на таргетный хост хоть на флешке в кармане, в дальнейшем подключив их к заданию.
Возникает закономерный вопрос: каков размер этих самых блоков? Он динамический и зависит от размера диска. Для простоты можно считать, что 1 Тб диска соответствует 1 Мб блока.
Как только VMDK перевезён, можно начинать создавать дельта диски. Для чего фильтр и демон начинают отслеживать IO машины, отправляя по сети всё, что пишется на машине.
Этот поток сознания, приходя на сорс прокси, проходит через процедуру отбрасывания лишних блоков. То есть если некий блок за период репликации был перезаписан несколько раз, то в дельту уйдёт исключительно последнее его состояние, а не вообще все. Это позволяет сохранять вагон ресурсов и два вагона пропускной способности вашей сети.
Рядом с дельта диском создаётся транзакцонный лог.
Если лог становится слишком большим, то создаётся новый дельта диск.
И так всё работает до достижения выбранного Retention policy. После чего Veeam смотрит на содержимое лога.
Если это просто устаревшая точка восстановления, которая нам больше не нужна, то данные из неё вносятся в наш базовый диск, и файлы удаляются.
Если оказывается, что в логе нет вообще ничего, необходимого для создания новых точек восстановления, такой файл сразу удаляется.
Примечание: Соблюдение Retention Policy довольно важно. Однако поддержка CDP реплики в боевом состоянии ещё важнее. Поэтому в механизм заложена потенциальная возможность временного расширения периода хранения до 125% от первоначального.
Long-term retention
Служит логическим продолжением short-term retention. То есть всё работает ровно так, как и написано выше, пока не наступает момент создать long-term точку.
В этот момент создаётся особый дельта диск. Внешне он не отличается от других, однако во внутренней логике он помечается как long-term delta.
Репликация продолжает идти своим чередом.
Когда подходит время для срабатывания short term, то все предыдущие логи и дельта диски (если их несколько) просто удаляются.
Теперь всё считается от этой long-term точки. Она остаётся нетронутой и высится как глыба.
Затем создаётся новая long-term точка, и цикл замыкается.
Когда подходит время, то самая первая long-term точка инжектируется в базовый VMDK.
Про логику транзакций
Путь данных с оригинальной машины до реплицированной можно разбить на два логических участка, водораздел которых проходит по source proxy.
Отсюда два важных следствия:
Если мы не успеваем передать данные на участке фильтр-демон-прокси, они считаются безвозвратно потерянными, и сделать с этим уже ничего нельзя.
На втором участке задержка уже не критична. Если даже в какой-то момент времени мы не успеваем получить подтверждение от таргетного демона, то данные остаются в кеше сорсного и таргетного прокси и будут переданы ещё раз. Если кажется, что такое кеширование избыточно, то это кажется. Сети сейчас, конечно, быстрые, но зачем лишний раз лезть далеко, если можно попросить данные ближе? В логе джобы в этот момент возникнет предупреждение, что RPO нарушено, но ничего критичного ещё не случилось. Позднее данные будут довезены до таргета.
Что под капотом у фильтров
Теперь, когда мы разобрались на базовом уровне в устройстве и принципах работы CDP, давайте посмотрим более внимательно на работу отдельных компонентов. А именно фильтров. Ведь именно от их красивой работы зависит всё остальное. И как мы все прекрасно понимаем, ровно и красиво может быть только в лабораторных условиях. Именно там у нас всегда стабильный поток IO операций, нет резких всплесков нагрузки, сетевые пакеты никуда не пропадают, и все графики выглядят как прямая рельса, уходящая за горизонт.
Вот так вот можно изобразить на любимых всеми квадратиках с буквами режимы работы. В данном примере у нас установлено RPO 10 секунд, из которых пять секунд (половина RPO) мы отслеживаем изменения данных, а вторую половину времени пытаемся передать последнее их состояние. То есть, промежуточные, как я говорил выше, нас не интересуют.
А вот что случается, когда мы не получаем подтверждение доставки от таргета. Данные мы собрали, однако передать их не можем. В этот момент Veeam начинает сохранять в сторонку номера таких блоков. И только номера, никаких данных. Почему? Потому что когда связь восстановится, нам надо передать актуальное состояние блоков.
Примечание: Чтобы администратор спал спокойней, предусмотрены два оповещения, скрывающихся под кнопкой RPO Reporting. Фактически они просто считают, сколько данных за указанный промежуток времени мы можем потерять. И бьют в набат, если что-то пошло не так.
Инфраструктура
Обычно, когда заходит речь о проработке какой-либо инфраструктуры, все сразу начинают думать про CPU и RAM. Но только не в этот раз! Здесь надо начинать с поиска вашего сетевика, чтобы он сделал вам сеть с наикратчайшим маршрутом, с 10 Gbit+ линками, и не забыл включить MTU 9000 (Release Jumbo frames. ) на всём протяжении маршрута. Согласно нашим тестам, такой набор нехитрых действий позволяет добиться прироста производительности почти на 25%. Неплохо, да?
И общий совет на все случаи жизни: десять маленьких CDP политик всегда будут работать лучше и стабильней, чем одна большая. Что такое маленькая политика? Это до 50 машин или 200 дисков. В мире большого энтерпрайза это считается за немного. Технически, опять же, здесь ограничений нет, и проводились успешные тесты аж до 1500 машин и 5000 дисков. Так что лучше, опять же, протестировать на месте и найти оптимальный для себя вариант.
Немного о прокси
И хотя кажется, что прокси серверам в схеме CDP отведена роль тупых молотильщиков трафика, без их успешного взаимодействия всё остальное теряет смысл. И задачи там решаются достаточно серьёзные, так что не будем принижать их вклад в общее дело.
Что хочется сказать про этих ребят:
Не надо заставлять один и тот же прокси сервер выступать в роли сорсного и таргетного. Ничего хорошего из этого не выйдет. Запретить вам так сделать мы не можем, однако будем долго отговаривать.
Да и вообще, общая логика такова, что чем больше вы сможете развернуть прокси серверов, тем лучше будет результат. Особенно если речь идёт о репликации между удалёнными дата центрами.
Также самые внимательные заметят, что на шаге назначения проксей есть кнопка Test с таинственным набором цифр внутри.
Давайте разбираться что же это такое и откуда оно взялось. Все эти скорости и количества являются ничем иным, как усреднёнными максимумами за последний час, полученными от vCenter. То есть это не мы что-то там померили в моменте, ловко запустив какие-то таинственные тесты, а такова родная статистика хостов за последний час.
Давайте теперь пройдёмся по строчкам.
Source Proxy CPU: количество ядер CPU на всех доступных проксях, которые могут работать в качестве сорса. Видим vCPU, но читаем как ядра CPU.
Source Proxy RAM. Здесь уже посложней будет. Цифра перед скобками показывает, сколько оперативки нам может понадобиться для данной CDP политики.
Формула расчёта довольно простая: RPO* пропускную способность.
Пропускную способность кого/чего? Да всех дисков всех вируталок, участвующих в этой политике. Напоминаю, что берётся максимальное значение за последний час.
Source Proxy Bandwidth. Здесь опять всё просто. Число перед скобками мы получаем от vCenter, а число в скобках считается на основе доступного количества ядер с округлением до целого. Если мы шифруем трафик, то это 150 Мб/с на ядро. Если не шифруем, то 200 Мб/с на ядро.
Target Proxy CPU. Всё ровно так же, как у сорса: взяли и посчитали все доступные ядра на доступных проксях.
Target Proxy RAM. Хочется, как и в предыдущем пункте, сказать, что всё такое же, но нет. Здесь в формулу для расчёта внесён поправочный коэффициент 0.5. А значит, что если мы за те же 15 секунд хотим обработать 150 Мб/c от дисков, то понадобится нам уже только 1125 RAM (вместо 2250, как это было с сорсом).
И помним важное: таргет и прокси меняются ролями в момент фейловера. То есть вся схема начинает работать в обратную сторону. Поэтому на таргете и есть неактивный фильтр, который оживает в момент фейловера. А фильтр на бывшем сорсе, соответственно, выключается.
Быстрое Ч.А.В.О. в конце
Как добавить в CDP Policy выключенную машину?
Никак. Виртуалка выключена > фильтр не работает > передавать нечего.
Какие версии vSphere поддерживаются?
Хочу минимальное RPO, чтобы ну вообще ничего не потерялось.
Если у вас железо хорошее (прям хорошее-хорошее, а не вам кажется, что хорошее), то вполне реально добиться RPO в 2 секунды. А так, в среднем по больнице, вполне реально обеспечивать 10-15 секунд.
А что с vRDM?
Всё отлично поддерживается.
А можно CDP прокси назначить и другие роли?
Назначайте, мы не против. Только следите за соответствием доступных ресурсов предполагаемым нагрузкам.
А можно CDP реплику, как и обычную, использовать для создания бекапов?
Нет. Во всяком случае сейчас.
Я могу запустить CDP реплику из консоли vCenter?
Нет. С точки зрения vCenter там какой-то фарш из дельта дисков, поэтому он выдаст ошибку зависимостей.
А если я руками удалю CDP реплику из Inventory в vCenter?
Умрут все id и всё сломается. А вы чего ожидали?
А если таргетная стора будет чем-то очень загружена?
Veeam будет присылать на почту уведомления, что очень старается, но у вас ботлнек на принимающей стороне и нельзя впихнуть невпихуемое.
А что с Hyper-V?
Это вопрос к Microsoft.
Немного полезных ESXi команд
Убить daemon сервис:
Остановить/запустить daemon сервис:
Полюбопытствовать насчет последних логов демона:
Выяснить, сколько памяти потребили все демоны:
Проверить установку пакета фильтра. Он выглядит как обычный vib