В этой статье мы хотим рассказать о результатах нагрузочного тестирования VBR для двух наиболее популярных режимов работы бэкап-прокси с учетом вариации количества параллельных задач.

Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam Backup&Replication (VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:

• Изучение документации и лучших практик по продуктам Veeam
• Разработку архитектуры VBR уровня сервис-провайдера
• Развертывание инфраструктуры VBR
• Тестирование решения, определение оптимальных настроек и режимов работы
• Запуск решения в промышленную (коммерческую) эксплуатацию

Как оказалось – не зря. Услуга стабильно функционирует, клиенты могут бэкапить свои виртуалки, а у нас появилась определенная экспертиза, которой мы хотим поделиться.

Здесь вы сможете увидеть:

• Описание production-инфраструктуры Selectel, использованной для тестирования
• Особенности работы бэкап-прокси (backup proxy) в различных транспортных режимах
• Описание программы тестирования и настроек компонентов VBR для её реализации
• Количественные показатели, их сравнение и выводы
• Конфигурация инфраструктуры для проведения тестов
• Инфраструктура-источник

В качестве платформы для тестирования производительности VBR выступил один из production-кластеров публичного Облака на базе VMware.

Аппаратная конфигурация хостов данного кластера:

• Процессоры Intel Xeon Gold 6140
• NVMe-накопители Intel DC P4600 и P3520
• 4 порта 10GbE на хост

В основе кластера лежат следующие решения:

• Физическая сеть – Ethernet-фабрика на коммутаторах Brocade VDX, архитектура Leaf-Spine (10GbE порты – подключение хостов, 40GbE аплинки до Spine)
• Среда виртуализации – VMware vSphere 6.5
• Хранение данных ВМ – VMware vSAN 6.6 (All-Flash кластер vSAN)
• Виртуализация сети – VMware NSX 6.4

Производительность платформы для тестирования более чем достаточна и не вызывает никаких сомнений. Конечно, для высокого быстродействия всё это должно быть правильно настроено, но поскольку это production, с живыми и довольными клиентами, можно быть уверенным, что и в этом плане всё хорошо.

Вместе с Облаком на базе VMware, Selectel запустил услугу для его бэкапа на платформе VBR. Заказчики получают web-портал самообслуживания, в котором могут выполнять бэкап и восстановление vApp и ВМ из своих VDC (виртуальный дата-центр).

Доступ клиентов к данному порталу (Veeam Enterprise Manager Self-service portal) осуществляется с теми же правами, что и к vCloud Director (vCD). Это возможно благодаря интеграции Veeam Backup Enterprise Manager (EM) и vCD, при этом каждый клиент при подключении к ЕМ ограничен ресурсами своих VDC, чужие ВМ он не увидит.

Клиенту не нужно разворачивать собственный VBR и связанную с ним инфраструктуру бэкапа, что предполагает затраты на вычислительные и сетевые ресурсы, хранилище, лицензии Veeam и MS, администрирование. Это долго, дорого и сложно. Selectel предоставляет основные возможности VBR как услугу BaaS (Backup-as-a-Service): мгновенно, просто, удобно, экономично.

Для предоставления данной услуги в Selectel была развернута провайдерская инфраструктура VBR, охватывающая все кластеры vSphere и VDC клиентов облака VMware, в том числе кластер, в котором проводилось данное тестирование. Таким образом, результаты тестов позволят судить о максимальной скорости, с которой клиенты смогут бэкапить свои ВМ.

Тестовые ВМ
Для тестирования производительности бэкапа в кластере vSphere было развернуто 6 идентичных ВМ в следующей конфигурации:

• ОС Windows Server 2016, 2 vCPU, 4GB RAM
• 200GB vDisk

Диск занят почти полностью – 193GB. Кроме файлов ОС, на нем создана папка с дистрибутивами различных ОС и СУБД объёмом 60GB (уникальные данные). На том же диске создано 3 копии данной папки – итого 180GB несистемных данных.

Никаких приложений на эти ВМ установлено не было, только «чистая» ОС и «холодные» данные. Никакой нагрузки, вычислительной или сетевой, не запускалось. В рамках данного тестирования этого не требовалось.

В кластере vSphere включен DRS, поэтому тестовые ВМ автоматически оптимально распределяются по хостам VMware ESXi для балансировки нагрузки.

Бэкап-прокси
ВМ с бэкап-прокси развернута непосредственно в описанном выше кластере vSphere (инфраструктура-источник, далее – кластер vSphere), это необходимое условие для тестирования в режиме Virtual Appliance.

Конфигурация ВМ:

• 8 vCPU
• 8GB RAM
• 40GB vDisk
• 10GbE vNIC vmxnet3
• ОС Windows Server 2016

Параметр «Max concurrent tasks» для бэкап-прокси на уровне VBR выставлен в значение 6. Это значит, что бэкап-прокси сможет одновременно (параллельно) обрабатывать до 6 задач (task) бэкапа. Один task – это бэкап одного виртуального диска ВМ.

Репозиторий бэкапа
В качестве фронтенда хранилища бэкапов выступает физический сервер, выполняющий роль бэкап-репозитория VBR. Конфигурация сервера:

• CPU Е5-1650v3
• 32GB RAM
• 2 порта 10GbE
• Бекенд хранилища – кластер CephFS c NVMe-кэшем.

Бэкап-репозиторий и узлы Ceph общаются по сети 10GbE, каждый из них подключен к коммутаторам двумя портами.

Подробное описание конфигурации кластера Ceph выходит за рамки данной статьи. Отметим, что для надежности и отказоустойчивости данные на нем хранятся в трех копиях. Производительность кластера не вызывает нареканий и заложена с запасом, результаты тестов показали, что ни в одном из них хранилище бэкапов не являлось узким местом.

Параметр «Limit maximum concurrent tasks» для бэкап-репозитория на уровне VBR выставлен в значение 6. Это значит, что бэкап-репозиторий сможет одновременно (параллельно) обрабатывать до 6 задач (tasks) бэкапа.

Сеть бэкапа
Физическая сеть описанной выше инфраструктуры ограничена полосой пропускания 10Гбит/с, везде используются коммутаторы и порты 10GbE. Это справедливо не только для сети vSAN, но и для менеджмент-интерфейсов хостов ESXi.

Для размещения бэкап-прокси на уровне VMware NSX создана выделенная подсеть со своим логическим коммутатором. Для её связности с физикой и осуществления маршрутизации развернут NSX-edge, размер X-large.

Забегая вперед, по результатам тестов видно, что сеть выдерживает нагрузку до 8Гбит/с. Это весьма солидная пропускная способность, которой на данном этапе хватает, при необходимости она может быть увеличена.

Схема взаимодействия компонент

Схема взаимодействия компонентов
Бэкап-прокси и тестовые ВМ развернуты внутри одного кластера VMware vSAN. После запуска задания бэкапа (бэкап-джобы) в зависимости от выбранного транспортного режима, особенности которых рассмотрены ниже, бэкап-прокси:

• Извлекает данные из бэкапируемых ВМ по сети vSAN (HotAdd) или по сети управления (NBD)
• Передает обработанные данные на бэкап-репозиторий по выделенной для этой цели подсети

Транспортные режимы бэкап-прокси
Бэкап-прокси (Backup proxy) является компонентом инфраструктуры VBR, непосредственно выполняющим обработку задания бэкапа. Он извлекает данные из ВМ, обрабатывает их (сжимает, дедуплицирует, шифрует) и отправляет на репозиторий, где они сохраняются в файлы бэкапа.

Бэкап-прокси позволяет работать в трёх транспортных режимах:

• Direct storage access
• Virtual appliance
• Network

Облако на базе VMware Selectel в качестве хранилища использует vSAN, в такой конфигурации Direct storage access не поддерживается, поэтому данный режим не рассматривается и не был протестирован. Оставшиеся два режима замечательно работают на каждом из наших кластеров vSphere, остановимся на них подробнее.

Режим Virtual appliance (HotAdd)
Virtual appliance – рекомендуемый режим при развертывании бэкап-прокси в виде ВМ. Хосты ESXi, на которых развернуты бэкап-прокси, должны иметь доступ ко всем Datastore кластера vSphere, хранящим бэкапируемые ВМ. Суть режима заключается в том, что прокси монтирует к себе диски бэкапируемых ВМ (VMware SCSI HotAdd) и забирает с них данные как с собственных. Извлечение данных происходит с Datastore по сети хранения.

В нашем случае бэкап-прокси ВМ должна находиться на одном из хостов ESXi кластера vSAN, который мы бэкапим. Извлечение данных происходит по сети vSAN. Таким образом, для работы в режиме Virtual appliance в каждом кластере vSAN должно быть развернуто минимум по одному бэкап-прокси. Развернуть пару бэкап-прокси (например, в менеджмент-кластере) и бэкапить ими все кластеры vSAN не получится.

Подробнее тут
blog.selectel.ru/nagruzochnoe-testirovanie-vbr-dlya-vmware/

В России с 1 января повышается НДС с 18% до 20%. К сожалению, это событие не обошло и нашу компанию
В течение декабря все ваши действующие тарифы будут перенесены в архив (они останутся по-прежнему активными, но не будут доступны для заказа), а с 1 января 2019 года будет увеличена стоимость тарифов с учетом увеличения ставки НДС.
bill.invs.ru/billmgr?func=register&lang=ru

Тарифы «+Мощность» для крупных проектов
Мощные тарифы виртуального хостинга от компании REG.RU — производительные решения, сочетающие в себе удобство shared и высокую скорость VPS. Интернет-магазины, СМИ, сайты компаний — им под силу даже самые тяжёлые проекты!

Попробуйте бесплатный тест-драйв на 14 дней!
Любой розничный клиент REG.RU может протестировать один из мощных VIP-тарифов хостинга в течение 14 дней совершенно бесплатно. За это время вы сможете в полной мере оценить все возможности услуги и сделать правильный выбор.
При использовании хостинга в тестовом режиме вам будут доступны те же функции и мощности, что и при платном заказе.

Подарки при каждом заказе
В подарок к мощным VIP-тарифам вы получаете полезные бонусы:

• до 4 новых доменов в зонах .RU и.РФ;
• бесплатное подключение SSL-сертификата на 1 год.

Закажите один из них и убедитесь лично во всех преимуществах хостинга от REG.RU!
www.reg.ru/hosting/

Уважаемые клиенты мы снова рады предложить вам аренду серверов в Чехии! Стабильность дата-центра, оптимальные пинги и быстрота реакции поддержки на любые инциденты всегда была визитной карточкой, а цены которые мы предложим вам, порадуют вас ещё больше.

Стандартные конфигурации:
1xE5-2620v2 / 16Gb / 1x500Gb SSD / IPMI / 100Mbps — 81 евро в месяц
1xE3-1230v3 / 16Gb / 1x500Gb SSD / IPMI / 100Mbps — 86 евро в месяц
1xE3-1230v5 / 16Gb / 1x500Gb SSD / IPMI / 100Mbps — 91 евро в месяц
+100Mbit/s +59 евро в месяц.
Возможна замена дисков, добавление памяти.
Индивидуальные конфигурации доступны по предварительному заказу и по очень хорошим ценам.

С наилучшими пожеланиями Park-Web.ru!

park-web.ru

Все знают, насколько важно Резервное копирование.

Итак, теперь мы комбинируя резервное копирование с каждым новым Dedicated заказа сервера в течение следующих нескольких дней!

Поместите заказ сервера между 3 — й и 7 декабря 2018 года и получить совершенно бесплатно резервного копирования пакета 10GB Acronis.

Перейти на сайт LEASEWEB, заказать выделенный сервер и выбрать агент Acronis Backup 10 ГБ свободного варианта. Ваш бесплатный архив будет добавлен в ваш счет, и он будет доступен до тех пор, пока вы по контракту. Например, если вы заказываете выделенный сервер в течение года, вы будете иметь Acronis Backup на весь срок действия контракта. Довольно милое дело, если вы спросите нас!

Заказ до 7 декабря 2018 года, и вы получите хранилище резервных копий Acronis в течение 5 рабочих дней.
www.leaseweb.com/acronis-promotion

В этом году – 10 лет, как запущен наш первый ЦОД OST-1. За это время мы с коллегами из службы эксплуатации и капитального строительства успели провести не одну модернизацию инженерной инфраструктуры дата-центра. Сегодня расскажу про самые интересные случаи.



200-тонный кран устанавливает новый чиллер Stulz на раму. Модернизация системы холодоснабжения системы дата-центра OST-1 в 2015 году.

Дата-центр – живой организм, он растет, меняется, ломается:) Все, что можно отнести к модернизации, я условно делю на:

• плановые замены и ремонты. Оборудование морально устаревает, истекает его срок эксплуатации. Такие работы мы бюджетируем, планируем и делаем без спешки, когда нам удобно (например, полный апргейд «внутренностей» ИБП или замену выработавших свой срок аккумуляторных батарей).
• ошибки проектирования. По заветам Uptime, все должно расходоваться и заканчиваться одновременно. Из-за неправильного проектирования баланс «холод – электричество – место» может нарушиться, например: есть куда ставить стойки, но зал уже не тянет по электричеству или кондиционированию. Самое неприятное с этими ошибками то, что всплывают они не сразу, а когда ЦОД приближается к проектной мощности.
• аварии. Бывает, что оборудование повреждается окончательно, бесповоротно и неожиданно, и его нужно менять.

На плановых заменах/ремонтах останавливаться не буду. Там практически все в нашей власти. Расскажу три истории об ошибках проектирования и послеаварийной модернизации.

История 1. Машинному залу не хватало холода
Это история про один из наших первых залов на Боровой. Он до сих пор работает. Зал с проектной мощностью 80 стоек по 5 кВт.

По мере заполнения зала перестало хватать холода: температура в холодных коридорах была выше, чем надо, постоянно возникали локальные перегревы. Это уже потом, с высоты своего опыта, мы поняли, что наделали ошибок в проектировании, и из-за этого страдало кондиционирование.




Какой-то «волшебной таблетки» от этих проблем мы тогда не видели, поэтому решили действовать поэтапно и по всем фронтам.

Сначала мы проверили, все ли оборудование установлено правильно и стоят ли заглушки в свободных юнитах. Мы также перепроверили раскладку перфорированных плиток и убрали лишние, установили дополнительные направляющие воздуха под фальшполом. Постарались найти и заделать все дырки, куда мог убежать холодный воздух. Советую вам тоже проверить, что у вас между кондиционером и стеной. Зазор в 5-7 см – это уже много.

Вот такой результат нам дало простое размещение заглушек в свободных юнитах.

Стало лучше, но недостаточно хорошо. Тогда мы решили изолировать холодные коридоры. Построили крышу, двери из поликарбоната. Получилось дешево и сердито. В результате мы избавились от паразитного смешения горячего и холодного воздуха и повысили КПД системы холодоснабжения.


Изолированный холодный коридор того же зала.

Мы понимали, что этого хватит ненадолго. С ростом ИТ-нагрузки нехватка мощности снова даст о себе знать.

Эту проблему попытались решить добавлением фреонового кондиционера, хотя зал работал на гликолевом охлаждении. Нас очень заботили габариты кондиционера (пройдет ли он в дверь, хватит ли угла поворота), поэтому подбирали модель с возможностью частичной разборки. Кондиционер установили не со стороны горячего коридора, как обычно это делают, а куда смогли втиснуть. Это добавило нам 80 киловатт по охлаждению.

Вот тот самый «гуттаперчевый» кондиционер Emerson.

Вся эта история оказалось непростой: нужно было придумать, как подвести фреоновые трассы до внешних блоков, как подвести к этим кондиционерам электричество, куда поставить внешние блоки кондиционера. Все это в работающем зале.

Просто для понимания, насколько там мало места.

После всех этих манипуляций мы избавились от локальных перегревов, температура распределялась равномерно в холодных и горячих коридорах. Получилось увеличить мощность зала и размещать в нем заявленные пятикиловаттные стойки.

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

История 2. В машинном зале закончились кондиционирование и энергоснабжение
Под клиента был спроектирован машинный зал на 100 стоек по 5 кВт. Проектная ширина стойки 800 мм, в каждом ряду 10 стоек. Потом клиент передумал заезжать, и зал сдавали на общих основаниях. В жизни стойки шириной 800 мм нужны в основном под сетевое оборудование, для всего остального нужны шестисотые. В итоге вместо 10 стоек в ряду у нас получилось 13, и еще оставалось место. А вот электричества и холода уже не хватало.

В ходе модернизации выделили новое помещение под два дополнительных ИБП по 300 кВт.

В зале появились дополнительные распределительные щиты.


Новую мощность нужно было распределить равномерно. Чтобы разделить новые и старые лучи, под фальшполом проложили отдельные кабельные лотки. Часть работающего ИТ-оборудования переключили на новые распределительные щиты поочередным переключением каждого луча питания.

Чтобы решить вопрос с нехваткой холода, поставили 1 дополнительный кондиционер на 100 кВт холода.


Во время такелажа, установки и пусконаладки всего оборудования зал продолжал работать в штатном режиме. Это было самым сложным моментом в проекте.

В результате модернизации мы добавили залу электричества и холода на еще 30 стоек по 5 кВт.

Проектная мощность и емкость зала увеличена на 30%.

История 3. Про замену чиллеров

Немного предыстории. Началось все в 2010 году, когда 3 чиллера дата-центра OST сильно пострадали во время урагана. Тогда, чтобы выжить, пришлось гонять чиллеры без защиты несколько суток, и компрессоры быстро загнулись. Сначала меняли их.

ИТ-нагрузка росла по мере заполнения ЦОД, а чиллеры Emicon так и не вышли на заявленную холодильную мощность. В 2012-м поставили дополнительный чиллер Hiref в ту же гидравлическую схему. Так мы прожили еще три года.

Со временем у чиллеров Emicon обострились эксплуатационные проблемы. Их мощности не хватало, поэтому в жару приходилось поливать водой из керхеров. С годами теплообменники обросли известковыми отложениями. В зазор между теплообменником фрикулинга и фреоновым конденсатором набивался тополиный пух и прочий мусор, который не удалишь из-за специфики строения теплообменников. Там образовался настоящий валенок, который не пропускал нормально воздух.

В 2015 году мы как раз закупали партию чиллеров Stulz для NORD-4. Решили под это дело заменить два из трех чиллеров Emicon. Теперь подробности.

Установка дополнительного чиллера Hiref без доустановки насосов. ИТ-нагрузка росла, а КПД чиллеров, пострадавших в урагане, падал. Летом резерва едва хватало. Мы решили добавить еще один чиллер, чтобы увеличить их суммарную мощность. На время работ система холодоснабжения должна была продолжать функционировать. Самое сложное в этой операции – организация гликолевого контура. Мы сделали гликолевую обвязку: от каждого чиллера было отведено гликолевое кольцо к новому чиллеру. Чиллеры поочередно выводили из эксплуатации, и подводили к новому чиллеру гликолевую трубу.


Фрагмент принципиальной схемы гидравлики. На ней видно, что от каждого из трех чиллеров были сделаны ответвления к новому чиллеру.

Основная задача этого чиллера – поддержка системы холодоснабжения летом. Благодаря Hiref у нас появился гарантированный резерв N+1 в жаркие месяцы. Но поврежденные в урагане чиллеры потихоньку начали издыхать, и нам пришлось задуматься об их замене.

Тот самый «летний» чиллер Hiref.

Замена Emicon на Stulz. Такие замены лучше делать осенью или весной: летом без резерва совсем страшно, а зимой просто неприятно проводить работы. Операцию запланировали на февраль/март, но готовиться начали еще в октябре.

За эти подготовительные месяцы мы проложили новые кабели, варили участки трубопровода, разработали план подъезда машины с оборудованием (на заднем дворе у нас тесно), очистили территорию для подъезда крана. Чиллеры предстояло менять в работающем дата-центре, и примерно на 1,5 суток он оставался без резервного чиллера. На этапе подготовки мы провели тесты, чтобы понимать, как дата-центр будет чувствовать себя без резерва, напридумывали различные ситуации, когда что-то могло пойти не так во время работ (например, длительный блэкаут во время замены чиллеров), и разработали план действий. Вот краткая хроника тех работ.
В ночь приехал чиллер. После успешного заезда крана на территорию дата-центра можно было начинать отключать старый чиллер.


Старый чиллер еще на месте, пока ведутся подготовительные работы. Варим раму для нового чиллера.

Потом к непосредственному месту работ должна была подъехать машина с чиллером. У нас там, мягко говоря, тесновато. Пришлось попотеть, чтобы вписаться во все эти сложные повороты в ограниченном пространстве.



Разобранный и распиленный пополам чиллер демонтировали.


Старый и новый чиллер отличаются размерами. Ушло еще какое-то время на подготовку металлической рамы. Дело осталось за подъемом и установкой чиллера.


На заднем плане фото видно, что параллельно довариваются участки гликолевого контура для нового чиллера.



После установки на раму монтируется вся гидравлика, чиллер подключают к электропитанию. В ночь делается опрессовка. На следующий день проходит пусконаладка и подключение к системе мониторинга.

На всю операцию ушло меньше двух суток: утром старый чиллер выключили, в конце следующего дня включили уже новый чиллер.

Через две недели меняли второй чиллер. Казалось бы, нужно было просто все сделать по отработанной схеме, но что-то пошло не так. Всю ночь шел снег. Сначала пришлось потратить время на расчистку территории, чтобы кран смог заехать. Начали демонтировать старый чиллер, как в двухстах метрах от нас ломается машина с новым чиллером. Точка невозврата уже пройдена, а у фуры сломался поворотный механизм колес прицепа (пульт управления от него).

Отремонтировать на месте не получилось, ездили за дополнительным пультом, который в субботу чудом оказался в офисе этой компании. С пультом удалось докрутить машину. В итоге на прохождение одного поворота у нас ушло больше 3 часов. Со всеми логистическими накладками работы растянулись до ночи. Хорошо, что мы продумали освещение для работ в темное время суток. Оставшиеся работы прошли в штатном режиме, и с понедельника в дата-центре заработал еще один новый чиллер.

В марте этого года мои коллеги провели замену уже третьего чиллера, последнего из переживших ураган. Теперь на Боровой работают три чиллера Stulz и один Hiref. Благодаря такой поэтапной модернизации у нас теперь есть большой запас по холоду, и мы не боимся самой жаркой погоды и тополиного пуха. Новые чиллеры поддерживают режим фрикулинга на большем температурном диапазоне, потребляют меньше энергии и работают очень тихо. Еще их очень удобно обслуживать из-за отдельных компрессорных отсеков: ремонтные работы можно проводить без полной остановки чиллера.

Недавно была побита рекордная цена доменного имени в новых gTLD. Домен Online.casino был продан за 510 тысяч долларов.

Таким образом домен опередил предыдущих рекордсменов — home.loans ($500 000) и vacation.rentals ($500 300).

Имя покупателя пока не разглашается.

Интересно также отметить, что еще в марте 2017 года был продан аналогичный домен, в котором имена первого и второго уровня занимают противоположные места — casino.online. Он был продан намного дешевле — за $201 250. Но в то время он тоже считался одним из самых дорогих доменов в новых gTLD.

www.webnames.ru

С момента создания в конце 2014 года не менялось.

hosting.kitchen/page/sitemap/

Было

Стало


Да, верно, давно уже делаю отдельные серверы под каждый блог ;)
Как обычно просто для истории.

Все серверы у меня еще и по локациям разбиты, чтобы если авария будет в ДЦ где, то какой-ниб из блогов да работал. И чисто как-то случайно так судьбой вышло, что этот блог в канадской локации тусуется.

Кстати больше чем у Хостобзора :) (старое)