Как правильно работать с данными о клиентском поведении?
В прошлой статье мы рассказывали про инструменты, которые позволяют нам строить отчеты и аналитику для управления клиентском опытом, искать инсайты в данных наших веб-платформ, с которыми взаимодействуют потребители, а также строить ML-модели, управляя их жизненным циклом. В этой статье поделимся, как собираем данные о клиентах и их действиях, как применяем полученные инсайты и мотивируем потребителей на дальнейшее сотрудничество с нами.
CDP — крутой инструмент для всех видов данных
Привет, меня зовут Паша, я руковожу Data Science-направлением в Центре развития финансовых технологий Россельхозбанка: от обычного анализа данных и заканчивая построением моделей машинного обучения. Я расскажу вам про наш опыт работы с клиентскими данными.
Итак, что у нас есть: несколько сайтов, преимущественно основанных на Vue Storefront (фронтенд) и Adobe Magento 2 (бэкенд), а еще приложение для iOS/Android. Для аналитики используем данные бэка, web-аналитики (Google Analytics и Яндекс.Метрика) и мобильной аналитики (Яндекс.AppMetrica). В этой экосистеме есть технологические особенности. Во-первых, данные бэка и web-аналитики живут отдельно; есть ограничения на выгрузку сырых данных из некоторых инструментов web-аналитики. Во-вторых, для персонализации платформы на основе этих данных необходимо привлечение ресурсов фронтенд-разработки и встраивание в релизный цикл.
CDP обходит все эти сложности. Только не думайте, что CDP — это Cloudera Data Platform, Continuous Data Protection или вовсе Cisco Discovery Protocol — вот и нет. Customer Data Platform или CDP — это класс систем, предназначенных для объединения данных о потребителях из различных источников, автоматизации маркетинга, персонализации коммуникаций и много чего еще.
Обычно CDP позволяет:
собирать данные о потребителях и их поведении в различных каналах
объединять их вокруг профиля клиента
сегментировать контактную базу
обеспечивать разнородные коммуникации с сегментами
строить аналитику и даже дашборды (например, для мониторинга качества трафика в разрезе источников)
Некоторые платформы расширяют возможности CDP встроенными модулями настройки и автоматизации цепочек коммуникаций, запуска экспериментов или построения прогнозных моделей. Такие платформы называются CD(X)P.
Кейс #1: как увеличить конверсию в сделки
В Россельхозбанке есть веб-платформа «Своё Фермерство» — это такой десктопный вариант супераппа для агропредпринимателей. Здесь вам и B2B-маркетплейс c популярными агропоставщиками, и площадка размещения товаров для B2C-продавцов. А еще каталог банковских услуг, бизнес- и агросервисов, поиск вакансий и сотрудников, доска частных объявлений и информационный ресурс с полезными материалами — все для фермеров в одном месте с целью оптимизации их деятельности. Удобно? Конечно! Остается только привести фермеров на эту веб-платформу и объяснить, куда они попали, как ей пользоваться и зачем. Задача весьма непростая, особенно принимая во внимание количество возможных сценариев использования сайта «Своё Фермерство» и разнородность аудитории.
В первом подходе мы решили:
сразу сориентировать пользователя на сайте и помочь ему найти, что искал
постепенно и в порядке релевантности рассказывать о других возможностях платформы
В рамках этого подхода с помощью CD(X)P мы реализовали несколько вариантов причем с минимальным привлечением ресурса разработки. Все необходимые аналитические отчеты мы также строили в CD(X)P. Это удобно: есть возможность «проваливаться» до посетителя, а интерфейс напоминает BI-инструменты. Начали с анализа входящего трафика, чтобы понять, как пользователи к нам попадают. Также нам надо было сегментировать и приоритизировать аудиторию.
Распределение входящего трафика (первые сессии)
Много пользователей приходят к нам с главной страницы сайта Россельхозбанка и партнеров, причем именно среди них самые низкие показатели возвращаемости, глубины просмотра и длительности сессий. Это можно объяснить относительно высоким трафиком на сайте банка и партнеров и тем, что оттуда на платформу «Своё Фермерство» приходит больше «случайных» посетителей, чем из других источников. Но справедливо предположить, что такими пользователями больше востребованы банковские услуги, а плохие показатели обусловлены тем, что посетители не понимают, куда они попали, и быстро возвращаются обратно на сайт банка или партнера.
Некоторые аналитические данные подтверждали эту гипотезу: например, среди посетителей, оставивших заявки на кредиты, соотношение источников первой сессии оказалось на стороне сайта Россельхозбанка. Так мы выделили первый сегмент пользователей, и теперь нужно было решить, как помочь им сориентироваться на «Своём Фермерстве» и добраться до заявок на кредиты именно на этой платформе, а не на сайте банка.
Можно было создать отдельный лендинг, но это потребовало бы разработки, а потестировать наши гипотезы об интересах посетителей хотелось поскорее и подешевле. Поэтому мы применили CD(X)P: инструмент позволяет настраивать показ элементов интерфейса и всплывающих окон в зависимости от посетителя из определенного сегмента.
Варианты коммуникаций «из коробки»
Мы попробовали несколько вариантов — баннер на главной странице «Своё Фермерство», всплывающее окно посередине экрана и всплывающую плашку внизу. В итоге для сегмента посетителей с сайта банка и партнеров нам удалось повысить длительность сессий более чем на 50%, а количество заявок — почти в два раза. Из вариантов коммуникации наиболее эффективно себя показал pop-up на главной странице.
Наш вариант pop-up и окна настройки: доступно A/B тестирование, управление расположением и условиями показа
Помимо этого, мы использовали CD(X)P для персонализации личного кабинета зарегистрированных пользователей сайта «Своё Фермерство»: мы начали с размещения разных баннеров в зависимости от отрасли пользователя (растениеводы/животноводы) и планируем развивать персонализацию дальше.
Кейс #2: как мотивировать клиентов оставлять отзывы и возвращаться за покупками
На нашей второй платформе «Своё Родное», где продают фермерскую продукцию для B2C, стояла похожая задача. К моменту анализа прошло уже около полугода, как платформа заработала в промышленном режиме, и несколько месяцев, как мы прикрутили к ней CD(X)P. Наступило время понять профиль посетителя «Своего Родного» и его поведение, чтобы сделать коммуникации более персонализированными. Также мы хотели разобраться, какие проблемы возникают при взаимодействии пользователя с платформой.
Перед нами стояли следующие бизнес-задачи:
замотивировать пользователей оставлять отзывы на фермерскую продукцию
вдохновить возвращаться к нам за новыми покупками
познакомить регионы с нашими продуктами
И CD(X)P здесь пришёлся очень кстати.
Увеличиваем количество отзывов
Когда посетитель заходит на нашу платформу за покупками, он может легко потеряться в разнообразии, поэтому его спасают отзывы других покупателей. Но нельзя оставить отзыв, если ты не заказывал товар. Когда мы впервые проанализировали эффективность написания отзывов на товары, оказалось, что конверсия купленных товаров в отзывы составляет 11%. То есть на каждый 9-й купленный товар клиенты оставляют отзывы. Неплохо? Вроде да, но есть подвох.
В каталоге представлено довольно много товаров. На момент проведения анализа их было 14 тысяч. На один купленный товар приходился 1 отзыв. При этом отзывов оставлено чуть более чем на 1% всех доступных на платформе товаров. Гипотеза — скорее всего, выбирая товар, пользователь смотрит на отзывы. Если они отсутствуют, то могут возникнуть сомнения покупать или нет, поэтому потребителей необходимо мотивировать оставлять отзывы после покупки. Более того, мы можем использовать отзывы, оставленные клиентами, при построении рекомендательных систем (кстати, их тоже можно строить в CD(X)P, но об этом расскажем в следующий раз) или при ранжировании товаров в выдаче.
В CD(X)P мы создали цепочку событий, которая запускается через неделю после того, как клиент купил товар. Тем самым мы даём ему время попробовать и оценить купленные продукты.
Сценарий рассылки push-уведомления с просьбой оставить отзыв на последнюю покупку
Через пару месяцев после начала этой рассылки в виде push-уведомлений на мобильные телефоны клиентов мы решили сравнить результаты «до» и «после» и они нас порадовали! Конверсия в отзыв после покупки выросла с 11% до 16%. В среднем на один товар на текущий момент приходится 2 отзыва вместо 1 ранее. Также сейчас более 5% всех товаров на площадке имеют хотя бы 1 отзыв (ранее, напомню, был 1%). При этом все результаты оказались статистически значимы.
Таким образом, CD(X)P позволяет нам выстраивать целые цепочки коммуникаций и настраивать их максимально гибко на основе тех пользовательских событий, которые мы же сами и логируем.
Возвращаем действующих клиентов за повторными покупками
Мы решили использовать CD(X)P, чтобы мотивировать клиентов на повторные покупки. Предварительно создав событие последнего заказа со всеми атрибутами и датой, мы построили цепочку коммуникаций для отработки сценария повторных закупок. Ориентируемся на последний сделанный клиентом заказ, ждем неделю после совершения им покупки и отправляем push-уведомления с напоминанием повторить заказ. При этом здесь можно легко и просто устроить A/B тест и отсылать, к примеру, альтернативный текст push-уведомления, чтобы по результатам тестирования понять, на какой из них лучше реагируют клиенты.
Сценарий рассылки push-уведомлений «Повторите заказ»
Масштабируем бизнес в регионы
Еще один показатель, который мы проанализировали — количество зарегистрированных пользователей и покупок в разбивке по регионам. Так как наша платформа ориентирована не только на Москву и Московскую область, нам, конечно же, было интересно, насколько популярна наша площадка в регионах.
Распределение посетителей по регионам (Москва и МО = 100%)
Видно, что распределение очень неравномерное, превалирует Москва и МО. Чтобы исправить это, мы решили проводить маркетинговые кампании, повышающие конверсии в покупку, и персонализировать их для топ-20 регионов по количеству новых пользователей. И в рамках этого кейса мы также планируем использовать CD(X)P.
А как вы автоматизируете маркетинг?
Здесь мы рассказали лишь малую часть того, что было сделано и планируется реализовать для улучшения взаимодействия клиентов с нашими веб-платформами. Мы поняли, что CD(X)P — действительно полезный инструмент, который значительно упрощает решение многих бизнес-задач, объединяя все доступные данные о посетителях в одном удобном месте. Кроме того, CD(X)P при настройке персонализации и автоматизации маркетинга снижает затраты на разработку.
Однако мы обнаружили, что на Хабре почти нет статей про внедрение и использование CD(X)P, поэтому решили делиться своей экспертизой и практикой. Если есть вопросы — спрашивайте в комментариях, мы обязательно ответим.
Cdp activity store что это
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Answered by:
Question
after clean install WS2016 w/all available update i have in System vent log:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.
Answers
>>The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
According to this error information, please check link below to fix issue:
Set Computer-wide Launch and Activation Permissions
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
All replies
>>after clean install WS2016 w/all available update i have in System vent log
Could you please provide details information of update to here for further troubleshooting?
Please open component Services, and then expand Component Services—>Computers—>My Computer, and then right-click application that you installed, click properties, select security tab, and change Authentication level for calls to be packet.
Please check link below for further understanding:
Setting an Authentication Level for a Server Application
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
is CDP Activity Store
All setting in Security tab is hidden:
>>The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
According to this error information, please check link below to fix issue:
Set Computer-wide Launch and Activation Permissions
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
Have you successfully resolved issue?
If there is anything we can do for you, please feel free to post in the forum.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
>>The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
According to this error information, please check link below to fix issue:
Set Computer-wide Launch and Activation Permissions
It is not generally recommended to change the computer-wide permissions to fix problems on just a couple DCOM objects. You see, you would be granting permissions to ALL objects that way. You should only change permissions on individual APPIDs that need them.
To fix your original problem, do the following:
If you receive no errors, then the change was successful. No reboot needed.
These commands grants SYSTEM permission to launch and activate RuntimeBroker & CDP*. The existing permissions and callbacks are preserved, and the registry permissions are not changed from defaults
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
