Я занимался этой проблемой около полугода (имел роскошь времени) и не смог ее решить, поэтому я, наконец, ушел в отставку и пришел сюда, чтобы попросить помощи у других, а не только у Google (наша поддержка vmware закончились около 3 лет назад, и наши руководители решили не заказывать продление через VMware).
Я не занимался производительностью виртуализации или виртуальных машин, все работает нормально. Я действительно получил удар в спину, когда мне нужно было установить новое программное обеспечение для резервного копирования виртуальных машин. Все хосты, хранилища и серверы резервного копирования оснащены сетевыми адаптерами 10GigEth и подключены к одному коммутатору 10Gig. Когда я хочу скопировать VMDK с хоста и его хранилища, подключенного к iSCSI, на сервер резервного копирования, скорость будет стабильной 150 Мбит / с. Объем резервного копирования, который мне приходится делать каждую ночь, составляет около 2–5 ТБ, и с такой скоростью это невозможно. Цель - увеличить скорость копирования как минимум до 100 МБ / с. (5 ТБ примерно за 14 часов).
Топология кластера
Коммутатор Dell 10 Gig действительно является сердцем кластера, поскольку все подключено к нему кабелем Cat6. Коммутатор SW2 подключается к нему шлейфом и служит точкой подключения для резервного подключения от хоста ESXi к сети X. На любом из этих коммутаторов нет других vlan, кроме 1 (по умолчанию). Все хосты и серверы подключены к VLAN A (или B), чтобы быть доступными из наших офисов и иметь доступ к Интернету, а также к остальной части корпоративной сети. Datasotres для кластера - это хранилища Dell (SFP) и HP (Copper), подключенные через iSCSI ко всем пяти хостам. Все хосты и серверы ESXi имеют медную связь Cat5 с SW3 в сеть Y, где также подключены все BMC и другие порты управления. На одном из резервных серверов включена маршрутизация для предоставления доступа к Интернету в сети X через сеть VLAN A. vMotion включен в сетях X и VLAN A. Все 10-гигабитные сетевые карты от устройств в сети X имеют большие кадры и сообщают о скорости 10 Гбит в полнодуплексном режиме.
Я тестировал довольно много программного обеспечения для резервного копирования, и, поскольку на испытательном стенде было только 100Base NIC, я не видел проблем с производительностью сети, но когда мы купили программное обеспечение, и я обнаружил, что скорость не будет превышать 150 Мбит / с, я понял что мне нужно сделать некоторые настройки. То, что я пробовал, следует. Скорость результата каждого теста составляла 150 Мбит / с. если не указано иное.
Я действительно могу сказать, в чем проблема, но, на мой взгляд, это было бы в ESXi. Виртуальные машины могут без проблем достигать скорости 500 МБ / с между собой на разных хостах, а сами хосты - нет.
Я буду очень признателен за каждый ответ на это и проясню каждую неясную деталь.
Мы используем veeam backup. он показывает нам, где и какой процент узких мест существует в нашей инфраструктуре резервного копирования: источник, сеть, цель. Источник - это данные, сеть чистая, а цель - это место, где мы храним резервную копию. У меня была та же проблема, и я обнаружил ее в скорости моего хранилища, и после этого узкое место изменилось на источник, и я добавил несколько прокси для резервного копирования, а затем сеть, изменив MTU мы решили эту проблему. Надеюсь, это поможет вам
Возможно, это не тот совет, которого вы ожидаете, но он решит вашу проблему ^^
Решение состоит в том, чтобы выполнять полное резервное копирование еженедельно, а не ежедневно.
Это один из первых реальных уроков, когда человек начинает делать резервные копии (и проверять их: D). Большие ежедневные резервные копии просто не завершаются в течение дня. Короче говоря, резервное копирование ТБ в день нецелесообразно, потому что хосты, сеть И хранилище просто не успевают за передачей.
Стандартная практика - резервное копирование максимум дневной разницы и еженедельного полного. VmWare имеет встроенные способы обработки инкрементных снимков, в зависимости от того, за какую версию вы платите. Посмотрите в ESXi, что вы можете настроить.
VmWare также будет более умным и не будет повторно копировать один и тот же контент по сети, держу пари, что огромный vmdk практически не меняется изо дня в день. Самый минимум для больших переводов - использовать rsync
вместо sftp
/scp
, rsync передает различие только для больших файлов.