VMware #1 — DRaaS медленная миграция

Звезды сошлись так, что часть инфраструктуры была в облаке как временное решение для переезда со старого железа на новое. Облако работало хорошо, но пришло время подрезать косты на облачко и решили инфру свезти на свое новое железо.

Но, ВНЕЗАПНО, мы столкнулись с проблемой низкой скорости миграции из облака к нам.

Было проверено все:
1. Железо 10Gbit
2. Стык 10Gbit+10Gbit
3. Настройки NIOC каких-то плюсов не дали
4. СХД на которую все ехало — All Flash с норм аплинками
5. Сетевая связанность — прямая L2
6. Ни QoS ничего сверх не накручено
7. vCAV ВМ — по нагрузке ок (если не более 4 заданий)

Заметилось интересное — что везти 1 ВМ, что 5 ВМ — скорость каждого потока миграции +- одинаковая 40-70Мб\сек, но общая пропускная способность не упирается. Т.е. за один час миграция могла прожевать + — 200Гб каждого потока. Но если поставить 5 заданий — то в час оно жевало 1Тб… но Жеванный Крот!

Чего мы только не делали, но скорость одного потока никогда не была выше чем некоторое значение (примерно, как на графике). Поддержка облачная прислала скрины, что с их стороны нет никаких ограничений.

Попросили дальнейший разбор полетов:

Алексей, ранее заметил, что внутри нашего облака между нашими площадками скорость репликации приблизительно аналогична вашей, задеплоил по рекомендациям ещё 2 репликатора для более равномерного распределения нагрузки, но согласно тестам внутри нашей инфраструктуры это не помогло решить проблему.  Поддержка ссылается на то, что в HBR на репликаторах есть механизм балансировки трафика, который не позволяет задействовать всю ширину канала для одной или нескольких точечных репликации. При увеличении количества репликаций, в данный момент у нас активных более 50, скорость по сравнению с тестами в начале деплоя vcav серьёзно уменьшилась. Мы договорились на разработку специального архитектурного решения конкретно для нашего кейса. Для этого нам необходимо проведение дополнительных тестов скорости Iperf на нашей стороны и предоставление желаемой скорости репликации коллегам из VMware.

Опачки, т.е. проблема воспроизводится и она реально есть и ее признали! Отлично! Ждем… Ждем… Что же вендор ответит?

Here is the mechanism the speed for a replication is calculated:

We have a component called HBR service which comes installed as a service on the replicator VM of vcloud availability stack.
HBRsrv is a low-level component which is communicating with replication IO filter in ESXi hosts. HBRsrv service is responsible to save VM deltas generated during RPO window on the destination datastore. HBRsrv is a common service for other VMware replication products and VCDA reuses it for moving replication data at the last mile.

Here how when data is reached to replicator VM  moves to the esxi host:

ESXi hosts Replicators communicate with hosts to:
1. Configure source VM for replication by enabling IO filter and configure it where to send replication data
2. Allocate resources in host for destination replication
These operations are done by HBRsrv service. For authentication purposes it needs to talk to hosts on 80/tcp, for data traffic it uses 902/tcp to hosts to send replication data for incoming replication and 44046/tcp from hosts to receive replication data for outgoing replications.

Here is the mechanism how the speed of the replication is controlled:

The rate of replication speed for VM is decided by HBR service as explained  is decided by below factor:
1. RPO of VM set
2. Last delta size for the VM
3. Time to complete the last delta sync

Using these factors hbrservice which runs in (replicator) determines how much to push to ensure delta will be synced without RPO violations and without impacting the other workloads/type of traffic in the network and it can balance the speed for other replicated VMs as well. We can understand in a environment if the environment is healthy by seeing the health status for VMS replicated.

So we can say that all the VMs in your environment are achieving the correct speed as they are not having any RPO violations and data is getting synced on time with correct speed needed for that particular VM.

The drops and highs in peak which you see while getting the data transfer depends on all these calculations which it does for a VM data and its deltas. I understand you have a bandwidth of 10 GB/S and you want to achieve a constant replication speed of at least 100 MB/s for replications for your clients replicated VM but we cant achieve a particular speed for a replication that HBR decides and calculates on its own for VMs based on the parameters as mentioned above. Unfortunately at this moment we don’t have mechanism to instruct HBR to achieve a particular speed for a replication.

Развернуть второй vCAV для теста — тоже нельзя:

К сожалению, в нашей конфигурации нельзя развернуть второй новый стек vcav, поскольку будет конфликт на уровне плагина vcav для vcloud director, ранее пытались это сделать и создавали кейс в поддержку на что получили ответ, что это невозможно.

По поводу скорости реплик, думаю, что стоит ждать решения о настройке приоритета репликаций или какого-либо подобного механизма, которое будет сделано в следующих глобальных обновлениях vCAV от VMware. Мы попробуем провести дополнительный research по вопросу скорости, но уверен, что получится что-то обнаружить, поскольку согласно всей собранной информации, проблема именно на уровне HBR сервиса.

Итого на русском: К сожалению, механизма с помощью, которого мы можем задать приоритет репликаций или что-то подобное на данный момент нет.