В OVHcloud группа доменных имен в настоящее время управляет в общей сложности 5 миллионами доменных имен. Чтобы справиться с этим объемом и предвидеть будущий рост, мы переводим нашу информационную систему с монолитной на архитектуру, основанную на микросервисах.

Хотя эта продолжающаяся миграция дает множество преимуществ по сравнению с монолитным подходом (наиболее очевидным является масштабируемость), по мере продвижения к нашей цели возникает несколько проблем. По своей природе микросервисы предполагают гораздо больше сетевых сообщений (в нашем случае HTTP) и имеют гораздо больше зависимостей от внешних служб; таких как базы данных, кеши, очереди и т. д. В этом контексте модульного тестирования каждой службы по отдельности недостаточно. Критически важным становится тестирование интеграции между всеми сервисами.



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

• Автоматизированная цепочка инструментов . Это очевидный вопрос; но автоматизация тестов значительно экономит время, поскольку позволяет нам запускать их автоматически на нашей платформе непрерывной интеграции при каждом отдельном изменении. Это также помогает нам создавать постоянно растущий набор тестов, которые действуют как цепочка без регрессии.
• Простые в запуске интеграционные тесты . Упрощение запуска интеграционных тестов, даже локально, повышает вероятность того, что команда будет их запускать, обновлять и писать в качестве подстраховки. Даже тесты, требующие нескольких взаимодействующих сервисов (базы данных, очереди, внешние API), должны легко запускаться.
• Простые в написании интеграционные тесты . Опыт разработчиков важен, команда с большей вероятностью напишет тесты, если это будет легко.

Тестирование в соответствующем масштабе

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

В OVHcloud службы домена развернуты следующим образом:



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

Поскольку эти службы предоставляют API-интерфейсы через конечные точки HTTP, тестирование API является идеальным способом их тестирования. Чтобы это работало эффективно, с сервисами следует обращаться как с черными ящиками, а тесты должны использовать только их API. Но на самом деле используется тестирование серого ящика. Это связано с тем, что мы знаем детали реализации сервисов и вводим наборы данных непосредственно в базы данных перед тестированием.

Как описано на диаграмме выше, если мы хотим протестировать службу Service 1, нам требуется, чтобы была доступна среда со шлюзом и, возможно, Service 2 или Service 3. Это быстро становится трудно настроить; особенно, если требуется протестировать все сервисы.

Итак, чтобы протестировать API сервиса, нам нужен способ изолировать его от других. Это то, что мы будем называть изолированными сервисными тестами в оставшейся части сообщения в блоге.

Изолированные сервисные тесты

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

• выполнять вызовы API или отправлять события,
• манипулировать базами данных,
• делать утверждения, используя:
  
  • ответы на вызовы API,
  • события, отправленные в очереди,
  
  
  • прямые запросы к базам данных.

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

Наши тесты выполняет тестовый раннер. Перед выполнением реальных тестов роль исполнителя тестов состоит в том, чтобы заполнить данные среды:

• базы данных заполняются с использованием стратегии «очистить, вставить» ,
• HTTP-макеты регистрируются на макетном сервере.

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



Эти тесты автоматически выполняются при каждом слиянии в промежуточной ветви службы и служат в качестве функциональных нерегрессионных тестов.

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

Интеграционные тесты

Цель этих тестов — развернуть все службы, управляемые группой доменных имен, в том же состоянии, что и в производственной среде. Мы по-прежнему используем имитирующий HTTP-сервер вместо HTTP-шлюза, потому что есть еще некоторые внешние службы, которые мы хотим имитировать. Но сервисы, принадлежащие нашей команде, не имитируются, мы их разворачиваем и регистрируем на макетном сервере как бэкенды.

Таким образом, мы можем соединить все наши сервисы вместе и имитировать только вызовы внешних сервисов.



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

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

Выполнение тестов

Технический стек

Описанный выше метод является универсальным и может применяться с использованием любых необходимых вам инструментов. Нам нужны абстрактные строительные блоки:

• тестовый бегун,
• фиктивный HTTP-сервер,
• платформа непрерывной интеграции.

Venom, средство выполнения декларативных тестов

Venom — это фреймворк для декларативного интеграционного тестирования, разработанный в OVHcloud. Venom предоставляет примитивы для выполнения HTTP-вызовов, управления базами данных и очередями сообщений и многого другого. Он также предоставляет мощный контекст для написания утверждений. Это совершенно необязательно, простые сценарии оболочки будут работать нормально, хотя они менее выразительны и их сложнее написать.

В Venom наборы тестов написаны на YAML. Это упрощает чтение и хранение наборов тестов вместе с исходным кодом тестируемой службы. Набор тестов — это просто последовательность тестовых примеров, состоящая из нескольких шагов. Шаги — это действия, последовательно выполняемые в службе или в ее среде, для которых мы можем выполнять утверждения.

name: Testing "Users" service
version: "2"
testcases:
    - name: Initialize database fixtures
      steps:
        - type: dbfixtures
          database: postgres
          dsn: "{{.postgres_dsn}}"
          migrations: ../../testdata/schemas
          folder: ../../testdata/fixtures
     
    - name: Try to retrieve data about user 313
      steps:
        - type: http
          method: GET
          url: "{{.service_url}}/api/v1/users/313"
          assertions:
            - result.statuscode ShouldEqual 200
            - result.bodyjson.id ShouldEqual 313
            - result.bodyjson.first_name ShouldEqual John
            - result.bodyjson.last_name ShouldEqual Doe
     
    - name: Try to update the name of user 313
      steps:
        # Perform the update
        - type: http
          method: PATCH
          url: "{{.service_url}}/api/v1/users/313"
          body: |
            {
              "first_name": "Jane",
              "last_name": "Smith"
            }
          assertions:
            - result.statuscode ShouldEqual 200
 
        # Check that the first name and last name were correctly updated
        - type: http
          method: GET
          url: "{{.service_url}}/api/v1/users/313"
          assertions:
            - result.statuscode ShouldEqual 200
            - result.bodyjson.id ShouldEqual 313
            - result.bodyjson.first_name ShouldEqual Jane
            - result.bodyjson.last_name ShouldEqual Smith

Приведенный выше набор тестов выполняет базовые тесты в службе CRUD «Пользователи». Сам набор тестов не запускает ни службу, ни ее зависимости, он предполагает, что они уже запущены.

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

Убийственная особенность Venom заключается в том, что он включает в себя множество исполнителей, которые могут потребоваться для тестирования любой службы с произвольными зависимостями: необработанные скрипты, HTTP, gRPC, SQL (MySQL и PostgreSQL), Redis, Kafka (производитель и потребитель), RabbitMQ., и даже SMTP и IMAP для проверки отправки электронной почты!

Smocker, имитирующий HTTP-сервер

Как показано выше, нам нужен сервер, который может позволить нам имитировать HTTP-ответы и моделировать поведение HTTP-шлюза.



Venom позволяет нам делать утверждения о возвращаемых значениях HTTP-вызовов и о состоянии технических зависимостей. Но поскольку он не предоставляет только те функции, которые нам нужны, мы прибегаем к другому инструменту, Smocker, разработанному для нашего случая использования. Он имеет пользовательский интерфейс, который неоценим для итеративного написания макетов.



Благодаря Смокеру мы также можем выполнить еще несколько важных утверждений о внутреннем поведении нашего сервиса:

• утверждать, что вызываются правильные конечные точки,
• утверждать, что их звонили нужное количество раз,
• утверждают, что они вызываются с правильной полезной нагрузкой.

Эти функции помогают нам лучше понять внутреннюю структуру тестируемых нами сервисов и помогают нам идти в ногу с эволюцией потока выполнения.

Во-первых, им нужно зарегистрировать моки через API. Мок — это просто файл конфигурации, который инициирует отправку заданного HTTP-ответа, когда к конечной точке делается определенный вызов. У макета может быть несколько фильтров; такие как метод, путь, параметры запроса и т. д. Он также содержит некоторую контекстную информацию; включая максимальное количество звонков на маршруте, задержку ответа и т. д.

- request:
    method: GET
    path: /users/313
    headers:
      X-Service-Destination: users-service
  response:
    status: 200
    headers:
      Content-Type: application/json
    body: |
      {
        "id": 313,
        "first_name": "John",
        "last_name": "Doe"
      }

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

CDS, платформа непрерывной интеграции

CDS (служба непрерывной доставки) — это полнофункциональная платформа непрерывной доставки и автоматизации, разработанная собственными силами OVHcloud. Это мощная альтернатива другим существующим платформам; такие как Jenkins, Travis или GitLab-CI. CDS позволяет нам создавать сложные рабочие процессы выполнения, работающие в различных средах (виртуальных машинах, контейнерах).





CDS предоставляет концепцию требований, которые мы широко используем для создания экземпляра ожидаемой среды для выполнения наших тестов. Эта функция позволяет нам быстро объявлять технические услуги, которые нам понадобятся во время выполнения тестов (базы данных, очереди, кеши и т. Д.). Он очень похож, например, на раздел «услуги», доступный в файле Travis.

Собираем все вместе

Тесты хранятся вместе с исходным кодом сервисов, как правило, следующих этой иерархии:

tests/
  venom/
    schemas/
      .sql
      ...
    fixtures/
      .yml
      ...
    mocks/
      test_suite.mocks.yml
    test_suite.yml

Для каждой службы цель — иметь возможность запускать тесты локально. Шаги включают:

• настроить технические зависимости (базы данных, кеши и т. д.) и фиктивный сервер в контейнерах Docker,
• использовать переменные в файлах тестов Venom, чтобы иметь возможность манипулировать ими с помощью Venom (инициализировать наборы данных, заполнить кеш и т. д.),
• назначить фиктивный сервер нашим HTTP-шлюзом, используя переменные среды при запуске службы,
• заполните переменные Venom при запуске теста.

Набор тестов Venom может выглядеть так:

version: "2"
name: Contacts endpoints testsuite
testcases:
- name: Save a new contact successfully
  steps:
  - type: dbfixtures
    database: postgres
    dsn: "{{.pgsql_dsn}}"
    migrations: ../schemas
    folder: ../fixtures
  - type: http
    method: POST
    url: "{{.mock_server}}/reset"
    assertions:
     - result.statuscode ShouldEqual 200
  - type: http
    method: POST
    url: "{{.mock_server}}/mocks"
    bodyFile: ./mocks/create_contact_mocks.yaml
    assertions:
     - result.statuscode ShouldEqual 200
  - type: http
    method: POST
    headers:
      Content-Type: application/json
    url: "{{.my_app}}/contacts"
    bodyFile: contact_create.json
    assertions:
     - result.statuscode ShouldEqual 201

Веном будет:

1. инициализировать базу данных, используя файлы миграции и фикстуры, доступные в  / schemas  и / fixtures ,
2. сбросить фиктивный сервер,
3. установить макеты в Smocker (макет сервера) с помощью

   .yml

    файла create_contact_mocks ,
4. вызвать службу, используя  файл contact_create.json в качестве полезной нагрузки, и сделать утверждения о результате.

Чтобы запустить этот тест, все, что нам нужно, это определить при запуске эти переменные Venom:

• pgsql_dsn : URL подключения к базе данных Postgres,
• mock_server : административный URL фиктивного сервера,
• my_app : URL-адрес службы для тестирования.

Эти переменные автоматически настраиваются в Makefile службы.

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

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

Как указано выше, технические зависимости, а также сервис объявлены как сервис в части требований задания CDS.



Это позволяет заполнить CDS, упомянутые выше переменные Venom следующим образом:

• pgsql_dsn : postgres: // myuser: password @ postgres / venom? sslmode = disable (пользователь, пароль и база данных устанавливаются с помощью параметров по требованию)
• mock_server : http: // mockserver: 8081 (порт администратора по умолчанию на Smocker)
• my_app : http: // myapp: 8080 (порт службы по умолчанию)

Благодаря командной строке Venom единственное, что осталось сделать в конвейере, — это выполнить тесты.



Конвейер тестирования включен в каждый из наших рабочих процессов, и развертывание в производственной среде обязательно блокируется, если какой-либо из тестов не проходит.

Ретроспектива

При настройке этих интеграционных тестов мы столкнулись с некоторыми трудностями:

• Срок изготовления был больше . Интеграционные тесты, выполняемые до того, как какое-либо развертывание помешало нам мгновенно развернуть исправления, они должны пройти тесты интеграции заранее. Это еще хуже, если исправление нарушает интеграционный тест. К счастью, в этом случае можно вручную принудительно выполнить развертывание через CDS.
• Интеграционные тесты часто довольно сложно поддерживать . Но формат YAML тестов и макетов позволяет нам комментировать их содержание, что облегчает поддержку.

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

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

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

Чтобы пойти еще дальше, сейчас мы думаем о внесении нескольких улучшений.

Покрытие кода

Наши микросервисы в основном написаны на Go. Go позволяет создать тестовый двоичный файл, включая профиль покрытия кода. Это можно использовать в дополнение к тестам Venom для генерации покрытия интеграционных тестов.

Покрытие кода — это полезная метрика, поскольку она позволяет обнаруживать участки кода, которые менее проверены.

Генерация документации

Поскольку Smocker, фиктивный HTTP-сервер, играет центральную роль в сетевом взаимодействии между сервисами, он может создавать диаграммы последовательности, описывающие поведение каждого вызова. Это можно использовать для динамического создания некоторых разделов нашей внутренней документации.

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



Гипергибкость — это часть ДНК OVHcloud; которые одновременно создают и разрушают парадигмы в сфере технологий и управления проектами.

Вернуться к основам

Управление доставкой — это функция применения процессов для обеспечения эффективной и действенной транспортировки товаров из одного места в другое.

Что такое управление доставкой? — onfleet.com/blog/what-is-delivery-management/

Управление доставкой — это тонкое искусство, особенно если речь идет о нестандартных проектах. Адаптация организации к конкретным проектам доставки требует опыта; такие как владение каскадными / гибкими методологиями управления проектами, понимание классических фреймворков, таких как Prince2 или SCRUM, и, прежде всего, здравый смысл при реагировании на конкретные потребности клиентов, особенно ключевых клиентов.

Облачная индустрия быстро развивается. Таким образом, ресурсы должны распределяться с еще большей бережливостью и гибкостью для достижения оптимального результата и для поддержания гипермасштабируемости (обусловленной ежедневной доставкой наших продуктов).

Прежде чем мы продолжим, вот несколько общих соображений:

• Большинство компаний имеют вертикальную структуру; например, отдел закупок, производственный отдел и отдел маркетинга.
• Однако заказчик использует продукты, для которых требуются все эти отделы, поэтому он не зависит от разрозненной структуры. Следовательно, необходимо преодолеть все разрозненные структуры с точки зрения доставки, чтобы предоставить ожидаемое решение.

Следовательно, управление доставкой следует рассматривать двумя способами:

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

Определение цепочки создания стоимости, начиная с потребностей клиента.

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

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

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

Цепочка простирается за пределы OVHcloud до последнего, решающего звена; что будет на стороне заказчика — этап доставки и приемки, с которого начинается использование решений.



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

Интегрируйте команды, ценив человеческие ресурсы

После того, как эта цепочка была визуализирована, встает вопрос об определении минимального количества участников, необходимого для каждого этапа реализации — определение SPOC (единой точки контакта) для каждого звена, при этом разделяя глобальное видение проекта всей командой проекта.. Как правило, мы организуем ограниченные встречи по синхронизации с нашими архитекторами и специалистами по продуктам, затем со специалистами по строительству, закупкам и производству и, наконец, с техническими специалистами центра обработки данных для окончательной настройки, имея в виду специально настроенные выделенные серверы. Модель 5D (обнаружение, определение, проектирование, разработка, реализация) будет полезна здесь для упорядочивания необходимых встреч на каждом этапе.

Для управления доставкой требуется сквозное, горизонтальное и сквозное видение всей цепочки доставки.

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



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

В двух словах

Определение и интеграция групп доставки по цепочке создания стоимости, начиная с клиента, позволяет менеджерам по доставке определять взаимозависимости, входы и выходы каждого звена; сохраняя при этом ставки и цели конкретных проектов доставки в гипермасштабируемой среде, в которой OVHcloud является европейским лидером. Этот ориентированный на клиента подход, позволяющий доставить ожидаемую ценность для клиента и за его пределами, является краеугольным камнем для OVHcloud.

Одним словом: управление доставкой OVHcloud, гипермасштабируемость.

В сети OVHcloud 34 точки присутствия (PoP); расположены в Европе, Северной Америке и Азиатско-Тихоокеанском регионе. Обладая глобальной пропускной способностью около 21 Тбит / с, сеть OVHcloud может обрабатывать гораздо больше трафика, чем другие провайдеры.

В OVHcloud сетевой трафик постоянно растет, чтобы удовлетворить потребности миллионов пользователей Интернета, которые используют 31 центр обработки данных по всему миру.

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

Дальнейшее расширение нашей сети

За почти два года исследований и разработок команда разработчиков сети OVHcloud создала совершенно новую инфраструктуру. Каждый центр обработки данных подключен к нескольким PoP (Point of Presence). PoP разделяют трафик с различными другими центрами обработки данных OVHcloud, а также обмениваются трафиком с разными поставщиками (известными как одноранговые узлы).

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

Обеспечение максимально возможной связи для наших клиентов по всему миру было движущей силой компании с момента ее создания Октавом Клаба. Для этого мы хотели быть максимально подключенными к местным провайдерам, для чего требовалось несколько портов со скоростью 10 или 100 Гбит / с.

Переосмыслив топологии PoP, мы рассмотрели новые масштабируемые технологии, в том числе:

• Пропускная способность порта: должна быть основана на портах 100 Гбит / с и 400 Гбит / с и иметь хорошую экономическую эффективность. Это поможет устранить любые узкие места в сети. Также необходимо было поддерживать каналы 10 Гбит / с для тех провайдеров, которые не были готовы к портам 100 Гбит / с.
• Легко обновлять:  новую архитектуру нужно было легко модернизировать с точки зрения емкости. Частично это сделано для роста компании, но также для поддержания доступности, когда на PoP требуется обслуживание сети.
• Мощность:  команде нужно было найти лучшее оборудование для максимального повышения эффективности энергопотребления; особенно в таких странах, как Сингапур, где это дорого.
• Безопасность: ключевым требованием будет работа с нашими группами безопасности, чтобы найти лучшее решение для защиты сети от угроз (массовых DDoS-атак).

После почти года исследований и испытаний команда дизайнеров разработала совершенно новую архитектуру; который был масштабируемым, энергоэффективным, простым в установке и надежным. Новая архитектура получила название SMAUG, в честь дракона из «Хоббита».

Обзор SMAUG

Чтобы быть адаптируемой, архитектура имеет несколько вариантов емкости в зависимости от того, насколько велик PoP. Это связано с тем, что в разных центрах обработки данных происходит обмен разным объемом трафика. Каждый вариант мощности имеет свою специфику, чтобы не было узких мест.

Инфраструктура Spine and Leaf

SMAUG — это инфраструктура «позвоночник и лист». Это означает, что «позвоночник» ( называемый SBB от SuperBackBone ) объединяет листья и соединяет каждый центр обработки данных. «Листовые» устройства ( называемые PB для PeeringBox ) используются для подключения провайдеров, а также внутренних служб, таких как оборудование xDSL или OVHcloud Connect.

Инфраструктура SMAUG также предоставляет другой способ подключения центра обработки данных, где есть как минимум два PoP, оба в другом месте. Например, в Сингапуре наш центр обработки данных подключен к двум точкам доступа, расстояние между которыми превышает 30 км — это соответствует правилу не использовать один и тот же источник питания для двух точек доступа.

Чтобы обеспечить избыточность, оба PoP должны быть подключены друг к другу с огромной пропускной способностью — в 100 Гбит / с или 400 Гбит / с, в зависимости от PoP. Группа передачи также участвовала в разработке новой инфраструктуры под названием «ГАЛАКТИКА». GALAXY была основана на другом конструкторе — в сочетании с простой в развертывании, масштабируемой, операционной моделью с меньшим энергопотреблением.

Роль листа довольно проста и похожа на верх стойки в центре обработки данных. Он имеет огромную пропускную способность восходящего канала к шипам и имеет конфигурацию для подключения одноранговых узлов BGP; такие как транзитные провайдеры, частные межсетевые соединения (PNI) и Интернет-обмен.

Роль позвоночника более сложная и имеет дополнительные функции, в том числе:

• Соединения дальнего следования:  он обеспечивает соединение каналов на основе 100 Гбит / с к центрам обработки данных и PoP.
• Маршрутизация: в  нем есть вся таблица маршрутизации, чтобы выбрать лучший путь к центрам обработки данных OVHcloud или к внешним сетям.
• Защита:  команда VAC участвовала в разработке нового инструмента защиты (для получения дополнительной информации:  https://www.ovh.com/blog/using-fpgas-in-an-agile-development-workflow/ ), чтобы чтобы помочь защитить всю сеть OVHcloud от DDoS-атак.
• Смягчение:  это также помогает системе обнаружения, используемой инфраструктурой VAC ( https://www.ovh.co.uk/anti-ddos/ )

Тестирование и развертывание

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

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

Вначале мы планировали провести эту миграцию в середине марта 2020 года и должны были отправить наших технических специалистов из Франции в Сингапур, но из-за COVID-19 нам пришлось изменить наши планы. Нам пришлось найти другое решение и попросить наших местных технических специалистов, работающих в нашем сингапурском центре обработки данных, выполнить эту работу. План миграции был более сложным из-за новой реорганизации, которую необходимо было провести в связи с пандемией.

После долгого обсуждения между руководством, сетевой командой и сингапурскими техниками OVHcloud было решено выполнить миграцию первого PoP в начале апреля, а второго — в конце апреля. Миграция началась с размещения новых устройств в двух новых стойках, подготовки проводки к миграции и выполнения некоторых проверок перед горячими заменами.

Переход на SMAUG

Давление на то, чтобы этот переход был успешным, был высоким, поскольку мы не хотели, чтобы он повлиял на наших клиентов. В первую ночь миграции — когда мы исчерпали трафик от первого PoP — мы попросили технических специалистов переместить все дальнемагистральные каналы в Сингапурский округ Колумбия, а для Австралии, Франции и США — на новые устройства. После некоторых тестов мы запустили новые устройства в производство. Первый шаг миграции прошел хорошо.

Следующий день был не таким уж и гладким, поскольку мы впервые запускали в производство наш новый Peering Box с нашей новой системой защиты границ, основанной на серверах FPGA. После того, как мы удалили трафик от наших пиров, трафик покидал сеть OVHcloud через второй PoP. Затем мы переместили волокна в новый Peering Box с помощью горячей замены от нашего поставщика центра обработки данных. После того, как мы все подключили к новому оборудованию, мы начали медленно возобновлять производство. Нам нужно было сделать это вместе с нашей командой безопасности, чтобы убедиться, что эта новая система защиты границ работает должным образом и не пропускает законный трафик.

В последний день миграции наша группа по передаче данных внедрила еще одну технологию. Целью здесь было увеличить пропускную способность между сингапурским центром обработки данных и точкой доступа, где мы установили эти новые устройства. После того, как мы изолировали трафик между обоими концами, мы переместили темное волокно в новую оптическую систему DWDM (Galaxy), чтобы добавить 400 Гбит / с пропускной способности центру обработки данных. Поскольку это было ново, у нас возникли проблемы с объяснением, как исправить некоторые проблемы с кабелями в системе. После того, как все было исправлено и готово, мы запустили 4 канала по 100 Гбит / с в производство.

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

Когда оба PoP были запущены в эксплуатацию, мы отслеживали, как он обрабатывает трафик и DDoS-атаки. Мы также связались с нашими близкими клиентами, чтобы убедиться в отсутствии проблем.

В заключение

Эта новая инфраструктура, SMAUG, обеспечивает значительные улучшения в области энергопотребления и экономии места, а также снижает сложность общей конструкции сети. Это также поможет OVHcloud не отставать от растущих требований к приложениям и услугам.

Забегая вперед, мы считаем, что гибкость конструкции SMAUG поможет OVHcloud увеличить пропускную способность сети и быть готовым к технологиям будущего.

Спасибо командам и отраслевым партнерам, которые помогли создать эту новую инфраструктуру.

Сегодня мы генерируем больше данных, чем когда-либо. 90 процентов глобальных данных были собраны за последние 2 года. По оценкам, к 2025 году объем данных в мире достигнет 175 зеттабайт. В общей сложности люди пишут 500 миллионов твитов в день, а автономные автомобили генерируют 20 ТБ данных каждый час. К 2025 году более 75 миллиардов устройств Интернета вещей будут подключены к Интернету, и все они будут генерировать данные. В настоящее время устройства и службы, генерирующие данные, есть повсюду.



Также существует понятие «исчерпание данных», которое является побочным продуктом онлайн-активности людей. Это данные, которые создаются в результате посещения кем-то веб-сайта, покупки продукта или поиска чего-либо с помощью поисковой системы. Возможно, вы слышали, что эти данные называются метаданными.

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

Но как мы можем обработать такой огромный объем данных? Конечно, по старинке сделать это невозможно. Нам необходимо модернизировать наши методы и оборудование.

Большие данные — это наборы данных, объем, скорость и разнообразие которых слишком велики для обработки на локальном компьютере. Итак, каковы требования к обработке «больших данных»?

1- Параллельная обработка данных

Данные есть везде и доступны в огромных количествах. Во-первых, давайте применим старое правило: «Разделяй и властвуй».

Разделение данных означает, что нам потребуется распределить данные и задачи обработки по нескольким компьютерам. Их нужно будет настроить в кластере, чтобы выполнять эти различные задачи параллельно и получить разумное повышение производительности и скорости.

Предположим, вам нужно было узнать, что сейчас в твиттере. Вам придется обработать около 500 миллионов твитов на одном компьютере за час. Не все так просто, правда? И как вы выиграете, если на обработку уйдет месяц? Какая ценность в том, чтобы найти тренд дня месяц спустя?

Распараллеливание — это больше, чем просто «хорошо иметь». Это требование!

2- Обработка данных в облаке

Второй шаг — это создание и эффективное управление этими кластерами.

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

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

И тогда, даже если вы решите использовать облачного провайдера, у вас будет несколько решений на выбор, каждое из которых имеет свои недостатки. Одно из этих решений — создать вычислительный кластер на выделенных серверах или экземплярах общедоступного облака и отправить в кластер различные задания по обработке. Главный недостаток этого решения заключается в том, что если обработка не выполняется, вы все равно платите за зарезервированные, но неиспользуемые ресурсы обработки.

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

Местоположение данных

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

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

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



Следовательно, использование облачных провайдеров, имеющих несколько регионов, дает компаниям преимущество наличия кластеров обработки рядом с их физическим расположением данных — это значительно сокращает время (и затраты!), Необходимое для получения данных.

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

3- Обработка данных с помощью наиболее подходящей технологии распределенных вычислений

Третий и последний шаг — решить, как вы собираетесь обрабатывать свои данные, то есть с помощью каких инструментов. Опять же, вы можете сделать это самостоятельно, реализовав механизм распределенной обработки на любом языке по вашему выбору. Но где в этом веселье? (хорошо, для некоторых из нас это может быть довольно весело!)

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

Apache Spark
Но есть технологии, которые были разработаны специально для этого. Они автоматически распределяют данные и обрабатывают задачи и получают результаты за вас. В настоящее время самой популярной технологией распределенных вычислений, особенно применительно к предметам Data Science, является Apache Spark.

Apache Spark — это распределенная среда кластерных вычислений с открытым исходным кодом. Он намного быстрее, чем предыдущий, Hadoop MapReduce, благодаря таким функциям, как обработка в памяти и отложенная оценка.

Apache Spark — ведущая платформа для крупномасштабного SQL, пакетной обработки, потоковой обработки и машинного обучения. Для кодирования в Apache Spark у вас есть возможность использовать разные языки программирования (включая Java, Scala, Python, R и SQL). Он может работать локально на одной машине или в кластере компьютеров для распределения своих задач.



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

Обработка данных OVHcloud (ODP)

OVHcloud — лидер европейских хостинговых и облачных провайдеров с широким спектром облачных сервисов, таких как публичное и частное облако, управляемый Kubernetes и облачное хранилище. Но помимо всех услуг хостинга и облачных сервисов, OVHcloud также предоставляет ряд услуг для анализа больших данных и искусственного интеллекта, а также платформ.

Одной из услуг обработки данных, предлагаемой OVHcloud, является обработка данных OVHcloud (ODP). Это служба, которая позволяет отправлять задание на обработку, не беспокоясь о кластере, стоящем за ним. Вам просто нужно указать ресурсы, необходимые для работы, и служба абстрагирует создание кластера и уничтожит его для вас, как только ваша работа будет завершена. Другими словами, вам больше не нужно думать о кластерах. Решите, сколько ресурсов вам понадобится для эффективной обработки данных, а затем позвольте OVHcloud Data Processing сделать все остальное.

Кластеры Spark для конкретных задач по запросу

Служба развернет временный кластер Apache Spark для конкретного задания, а затем автоматически настроит и защитит его. Вам не нужно иметь никаких предварительных знаний или навыков, связанных с облаком, сетями, системами управления кластерами, безопасностью и т. Д. Вам нужно только сосредоточиться на своем алгоритме обработки и коде Apache Spark.

Эта служба загрузит ваш код Apache Spark из одного из ваших контейнеров объектного хранилища и спросит вас, сколько ОЗУ и ядер ЦП вы хотели бы использовать в своей работе. Вам также нужно будет указать регион, в котором будет выполняться обработка. И последнее, но не менее важное: затем вам нужно будет выбрать версию Apache Spark, которую вы хотите использовать для запуска вашего кода. После этого служба запустит ваше задание в течение нескольких секунд в соответствии с указанными параметрами до его завершения. Больше нечего делать с твоей стороны. Ни создания кластера, ни разрушения кластера. Просто сосредоточьтесь на своем коде.

Ресурсы вашего локального компьютера больше не ограничивают объем данных, которые вы можете обработать. Вы можете запускать любое количество заданий обработки параллельно в любом регионе и любой версии Spark. Это также очень быстро и очень просто.

Как это работает?

На вашей стороне Вам просто необходимо:

1. Создайте контейнер в OVHcloud Object Storage и загрузите в этот контейнер код Apache Spark и любые другие необходимые файлы. Будьте осторожны, чтобы не помещать свои данные в один и тот же контейнер, так как весь контейнер будет загружен службой.
2. Затем вам нужно определить механизм обработки (например, Apache Spark) и его версию, а также географический регион и количество необходимых ресурсов (ядер ЦП, ОЗУ и количество рабочих узлов). Есть три разных способа выполнить это (панель управления OVHcloud, API или ODP CLI)

Это разные шаги, которые происходят при запуске задания обработки на платформе OVHcloud Data Processing (ODP):

1. ODP возьмет на себя управление развертыванием и выполнением вашей работы в соответствии с заданными вами спецификациями.
2. Перед тем как начать работу, ODP загрузит все файлы, которые вы загрузили в указанный контейнер.
3. Затем ODP выполнит вашу работу в специальной среде, созданной специально для вашей работы. Помимо ограничения на доступные порты (список доступен здесь ), ваша работа может затем подключиться к любому источнику данных (базам данных, хранилищу объектов и т. Д.) Для чтения или записи данных (если они доступны через Интернет)
4. Когда задание завершено, ODP сохраняет журналы вывода выполнения в ваше объектное хранилище, а затем немедленно удаляет весь кластер.
5. С вас будет взиматься плата за указанное вами количество ресурсов и только за время расчета вашего задания на поминутной основе.

Различные способы подачи заявки?

Есть три различных способа отправить задание на обработку в ODP, в зависимости от ваших требований. Этими тремя способами являются OVHcloud Manager, OVHcloud API и CLI (интерфейс командной строки).

1. OVHcloud Manager
Чтобы отправить задание с помощью OVHcloud Manager, вам необходимо перейти на OVHcloud.com и войти в свою учетную запись OVHcloud (или создать ее, если необходимо). Затем перейдите на страницу «Общедоступное облако», выберите ссылку «Обработка данных» на левой панели и отправьте задание, нажав «Начать новое задание».

Перед отправкой задания вам необходимо создать контейнер в OVHcloud Object Storage, щелкнув ссылку «Object Storage» на левой панели и загрузить свой код Apache Spark и любые другие необходимые файлы.

2. OVHcloud API
Вы можете отправить задание в ODP с помощью OVHcloud API. Для получения дополнительной информации вы можете посетить веб-страницу API OVHcloud api.ovh.com/. Вы можете создать автоматизацию отправки заданий с помощью ODP API.

3. ODP CLI (интерфейс командной строки)
ODP имеет интерфейс командной строки с открытым исходным кодом, который вы можете найти в общедоступном GitHub OVH по адресу github.com/ovh/data-processing-spark-submit ). Используя CLI, вы можете загружать свои файлы и коды и создавать кластер Apache Spark с помощью всего одной команды.

Некоторые преимущества ODP

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

• Не требуется никаких навыков или опыта в управлении кластером или настройке .
• Не ограничен в ресурсах и легко и быстро. (Единственное ограничение — это квота вашей облачной учетной записи) 
• Модель с оплатой по мере использования с простой ценой и без скрытых затрат. (поминутная оплата)
• Определение ресурса для каждого задания (больше ресурсов не теряется по сравнению с объединенным кластером) 
• Простота управления версией Apache Spark (вы выбираете версию для каждого задания, и вы даже можете иметь разные задания с разными версиями Apache Spark одновременно) 
• Выбор региона (вы можете выбрать разные регионы в зависимости от местоположения данных или политики конфиденциальности данных)
• Начните обработку данных всего за несколько секунд
• Журналы в реальном времени (когда ваша работа выполняется, вы будете получать журналы в реальном времени на панели клиентов)
• Полный выходной журнал будет доступен сразу после завершения работы (некоторым конкурентам требуется несколько минут, чтобы доставить вам журналы)
• Автоматизация отправки заданий (с помощью ODP API или CLI)
• Конфиденциальность данных (OVHcloud — европейская компания, и все клиенты строго защищены европейским GDPR)

Вывод

С развитием новых технологий и устройств нас наводняют данные. Для бизнеса и научных исследований все более важно обрабатывать наборы данных и понимать, в чем заключается ценность. Предоставляя услугу обработки данных OVHcloud (ODP), наша цель — предоставить вам одну из самых простых и эффективных платформ для обработки ваших данных. Просто сосредоточьтесь на своем алгоритме обработки, а все остальное ODP сделает за вас.

Вступление

С почти 6000000 веб-сайтов, размещенных на более чем 15000 серверах, команда OVHcloud Webhosting SRE управляет множеством предупреждений в течение рабочего дня.

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

Поэтому нам нужны инструменты, которые нам помогут. В нашей команде мы называем это самоисцелением.

Что такое самоисцеление ?

Selfheal относится к автоматизации решения оповещения в производственных условиях. Автоматизированный процесс может исправить известные проблемы без вмешательства администратора.

Зачем нам это нужно?

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

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

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

Оборудование

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

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

Мы не можем позволить себе тратить часы на повторяющиеся задачи, если их можно автоматизировать.

Программного обеспечения

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

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

Мы должны как можно меньше предупреждать дежурных администраторов, только когда это абсолютно необходимо.

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

Selfheal на веб — хостинг

В Webhosting мы разделяем selfheal на две части:

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

В этой статье мы обсудим внешнюю часть.

Внешнее самоисцеление

Контекст:

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

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

Мы могли выбрать существующий инструмент (например, StackStorm), но мы этого не сделали. Вот почему:

• Создание микросервисов в OVH действительно просто и быстро.
• Структурированные, подробные и простые журналы с уникальным идентификатором uuid для отслеживания каждой задачи самовосстановления в нашей внутренней системе журналов (что позволяет нам легко строить графики). 
• Простая интеграция с нашими существующими инструментами и экосистемой 
• Быстрое и простое развертывание во всех наших регионах
• Простой CI / CD (модульное тестирование и т. Д.)
• Пользовательские уведомления, например чат-бот
• Интеллект и история

Как это устроено

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

Приложение использует события Kafka, а затем мгновенно реагирует на правильный рабочий процесс, в зависимости от проблемы.

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

Все выполненные действия сохраняются. Это избавляет от необходимости выполнять одно и то же исправление несколько раз на данном сервере и выявлять сложные проблемы.

Конкретный пример замены неисправного диска

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

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

Чтобы управлять этим предупреждением, администратор должен был выполнить следующие действия:

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

Весь этот процесс может занять до 3 часов и его сложно выполнить вручную (управление несколькими проблемами одновременно).

Первое, что мы сделали, — автоматизировали проверку зондом.

Затем мы решили автоматизировать все это с помощью простого рабочего процесса в нашем приложении с самовосстановлением, а затем организовать вызов API.



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

Заключить

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

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

Оповещения обрабатываются мгновенно при обнаружении системой мониторинга. Это помогает нам вести чистый список невыполненных работ по мониторингу и избегать «пакетных» решений по оповещениям, которые были сложными как для нас, так и для DC.

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

Что такое PCI-Express?

Все, и я имею в виду все, должны обращать внимание, когда они проходят интенсивное обучение машинному обучению / глубокому обучению.

Как я объяснял в предыдущем сообщении блога, графические процессоры значительно ускорили эволюцию искусственного интеллекта.



Однако создать сервер на графических процессорах не так-то просто. А отсутствие соответствующей инфраструктуры может сказаться на времени обучения.

Если вы используете графические процессоры, вы должны знать, что есть 2 способа подключить их к материнской плате, чтобы позволить ей подключаться к другим компонентам (сети, ЦП, устройству хранения). Решение 1 — через PCI Express, а решение 2 — через SXM2 . Мы поговорим о SXM2 в будущем. Сегодня мы сосредоточимся на PCI Express . Это связано с тем, что он сильно зависит от выбора соседнего оборудования, такого как шина PCI или ЦП.



Дизайн SXM2 VS Дизайн PCI Express
Это основной элемент, который следует учитывать при разговоре о глубоком обучении, поскольку этап загрузки данных — это пустая трата времени вычислений, поэтому пропускная способность между компонентами и графическими процессорами является ключевым узким местом в большинстве контекстов обучения глубокому обучению.

Как работает PCI-Express и почему нужно заботиться о количестве линий PCIe? Что такое линии PCI-Express и есть ли связанные с этим ограничения ЦП?

Каждый GPU V100 использует 16 линий PCI-e. Что именно это означает?



В «х16» означает, что PCIe имеет 16 выделенных полос. Итак… следующий вопрос: что такое полоса PCI Express?

Что такое линия PCI Express?

Дорожки PCIe используются для связи между устройствами PCIe или между PCIe и ЦП. Полоса состоит из двух проводов: один для входящей связи, а другой с удвоенной пропускной способностью трафика для исходящего.

Связь по дорожкам похожа на связь сетевого уровня 1 — все дело в максимально быстрой передаче битов по электрическим проводам! Однако метод, используемый для PCIe Link, немного отличается, поскольку устройство PCIe состоит из линий xN. В нашем предыдущем примере N = 16, но это может быть любая степень двойки от 1 до 16 (1/2/4/8/16).

Итак… если PCIe похож на сетевую архитектуру, это означает, что уровни PCIe существуют, не так ли?

Да! Вы правы, PCIe имеет 4 слоя:



Физический уровень (также известный как уровень больших переговоров )

Физический уровень (PL) несет ответственность за ведение переговоров условия для получения исходных пакетов (PLP для пакетов физического уровня) , то есть ширина полосы частот , и с другим устройством.

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

Пакеты, полученные на физическом уровне (также известный как PHY) , поступают от других устройств PCIe или из системы (например, через память прямого доступа — DAM или от ЦП) и инкапсулируются в кадр.

Назначение Start-of-Frame — сказать: «Я отправляю вам данные, это начало», и для этого требуется всего 1 байт!


Слово « конец кадра» также составляет 1 байт, чтобы сказать «до свидания, я сделал это».


Этот уровень реализует декодирование 8b / 10b или 128b / 130b, которое мы объясним позже и в основном используется для восстановления тактовой частоты.

Пакет уровня канала передачи данных (он же давайте разберем этот беспорядок в правильном порядке )

Пакет уровня канала передачи данных (DLLP) начинается с порядкового номера пакета. Это действительно важно, поскольку в какой-то момент пакет может быть поврежден, поэтому может потребоваться однозначная идентификация для повторных попыток. Порядковый номер кодируется на 2 байта.

Layer Data Link Packet затем следуют уровне транзакций пакетов , а затем закрывается с МЦРК (Local Циклические Redundancy Check) и используется для проверки слоя транзакции пакета (значение фактического Payload) целостность.

Если LCRC подтвержден, то уровень звена данных отправляет сигнал ACK (ACKnowledge) на передатчик через физический уровень . В противном случае он отправляет сигнал NAK (Not AcKnowledge) на передатчик, который повторно отправит кадр, связанный с порядковым номером, для повторной попытки; эта часть обрабатывает буфер воспроизведения на стороне получателя .

Уровень транзакций

Уровень транзакции отвечает за управление фактической полезной нагрузкой (заголовок + данные), а также (необязательный) дайджест сообщения ECRC (сквозная циклическая проверка избыточности) . Этот пакет уровня транзакции поступает с уровня звена данных, где он декапсулирован .

При необходимости / запросе выполняется проверка целостности . Этот шаг будет проверять целостность бизнес - логику и не будет гарантировать , нет коррупции пакетов при передаче данных от Data Link Layer для транзакций уровня.

Заголовок описывает тип транзакции, например:

• Операция памяти
• Транзакция ввода-вывода
• Транзакция конфигурации
• или сообщение транзакции

Уровень приложения

Роль прикладного уровня  — обрабатывать логику пользователя . Этот уровень отправляет заголовок и полезные данные на уровень транзакции . Магия происходит на этом уровне, где данные привязаны к разным аппаратным компонентам.

Как PCIe общается с остальным миром?

PCIe Link использует концепцию коммутации пакетов, используемую в сети в полнодуплексном режиме.

Устройство PCIe имеет внутренние часы для управления циклами передачи данных PCIe . Этот цикл передачи данных также организуется благодаря ссылочным часам. Последний отправляет сигнал через выделенную полосу (которая не является частью x1 / 2/4/8/16/32, упомянутой выше) . Эти часы помогут как принимающим, так и передающим устройствам синхронизироваться для передачи пакетов.

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

У вас может быть порядок байтов, но есть ли у вас целостность данных на физическом уровне?

Для обеспечения целостности устройство PCIe использует кодировку 8b / 10b для PCIe поколений 1 и 2 или схему кодирования 128b / 130b для поколений 3 и 4.

Эти кодировки используются для предотвращения потери временных ориентиров, особенно при передаче последовательных одинаковых битов. Этот процесс называется « Восстановление часов ».

Эти 128 бит данных полезной нагрузки отправляются, и к ним добавляются 2 байта управления.

Быстрые примеры

Давайте упростим это на примере 8b / 10b: согласно IEEE 802.3, пункт 36, таблица 36–1a на основе спецификаций Ethernet здесь представляет собой кодировку таблицы 8b / 10b:



Итак, как получатель может различить всех, кто повторяет 0 (имя кодовой группы D0.0)?



Кодирование 8b / 10b состоит из кодировок 5b / 6b + 3b / 4b.

Следовательно, 00000 000 будет закодировано в 100111 0100, 5 первых битов исходных данных 00000 будут закодированы в 100111 с использованием кодирования 5b / 6b ( rd + ); то же самое касается второй группы из 3 бит исходных данных 000, закодированных в 0100 с использованием кодирования 3b / 4b ( rd- ).

Это могло бы быть также 5b / 6b кодирования й + и 3b / 4b кодирование RD- решений 00000 000 превращается в 011000 1011

Следовательно, исходные данные, которые были 8-битными, теперь являются 10-битными из-за управления битами (1 управляющий бит для 5b / 6b и 1 для 3b / 4b).

Но не волнуйтесь, я позже напишу в блоге сообщение, посвященное кодированию.

PCIe поколения 1 и 2 были разработаны с кодированием 8b / 10b, что означает, что фактические передаваемые данные составляли только 80% от общей нагрузки (поскольку 20% — 2 бита используются для синхронизации часов).

PCIe Gen3 и 4 были разработаны с 128b / 130b, что означает, что управляющие биты теперь составляют только 1,56% полезной нагрузки. Неплохо, не правда ли?

Давайте вместе рассчитаем пропускную способность PCIe

Вот таблица спецификаций версий PCIe



Консорциум PCI-SIG Теоретическая пропускная способность PCIe / Технические характеристики полосы / пути



консорциум PCI-SIG PCIe теоретическая необработанная спецификация скорости передачи данных. Чтобы получить такие числа, давайте посмотрим на общую формулу пропускной способности:

• BW означает пропускную способность
• MT / s: мегапереводы в секунду
• Кодирование может быть 4b / 5b /, 8b / 10b, 128b / 130b,…

Для PCIe v1.0:

Таким образом, с 16 полосами для NVIDIA V100, подключенными к PCIe v3.0 , эффективная скорость передачи данных (пропускная способность данных) составляет почти 16 ГБ / с / путь ( фактическая пропускная способность составляет 15,75 ГБ / с / путь ).

Вы должны быть осторожны, чтобы не запутаться, поскольку общую пропускную способность также можно интерпретировать как двухстороннюю пропускную способность; в этом случае мы считаем, что общая пропускная способность x16 составляет около 32 ГБ / с.

Примечание: Еще один элементкоторый мы не рассматривал, что максимальные потребности теоретической пропускной способности будут снижены примерно1 Гбит / с для протоколов коррекции ошибок ( ЦЭР и МЦРК ), а также в заголовках ( Начальный тег, последовательность теги, заголовок ) иНакладные расходы на нижний колонтитул ( конечный тег) объяснялись ранее в этом сообщении в блоге.

В заключение

Мы видели, что PCI Express сильно изменился и основан на тех же концепциях, что и сеть. Чтобы извлечь максимум из устройств PCIe, необходимо понимать основы базовой инфраструктуры.

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

Подводить итоги:

Друзья не позволяют друзьям создавать собственные хосты на GPU

Повторяя вчерашнее объявление в блоге Jupyter, OVHcloud гордится тем, что поддерживает JupyterCon в качестве платинового спонсора и донора инфраструктуры.



Как вы, наверное, знаете, Jupyter стал огромным фактором развития сообщества программистов, поддерживая более 140 ядер, таких как Python, R, Julia, Spark, Sas, Haskell, Ruby, C ++, Go и т. Д.

Проект Jupyter воплощает в себе открытые и совместные сообщества разработчиков, которые являются ключевыми ценностями в структуре нашей собственной экосистемы.

В последние годы Jupyter и OVHcloud работали рука об руку над такими проектами, как Mybinder.org и NbViewer. Я хотел бы поблагодарить совет директоров Jupyter и NumFocus за их открытость и доверие, которые сделали возможным такое успешное партнерство.

В 2020 году мы пошли дальше, предложив поддержку JupiterCon в течение всего года и помогая внести свой вклад в успех мероприятия.

С переходом на полностью цифровой опыт ограничения на поездки COVID-19 представляют собой возможность не только сократить расходы на поездки и упростить доступ, но и ограничить углеродный след, связанный с обменом знаниями в экосистеме.

OVHcloud, европейский лидер в области размещенного частного облака!

OVHcloud был признан лидером на европейском рынке размещенного частного облака согласно последнему отчету Forrester о размещенных частных облачных услугах в Европе, второй квартал 2020 года. Нас отметили за способность унифицировать услуги при обеспечении эмансипированного европейского предложения в соответствии с Законом об облачных технологиях.

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

Forrester Wave ™

В OVHcloud мы являемся глобальным облачным игроком, предоставляющим полную свободу выбора своим клиентам через 4 категории продуктов (Hosted Private Cloud, Baremetal Cloud, Public Cloud и Web Cloud), которые полностью взаимосвязаны и предназначены для всех вариантов использования клиентов.

В отчете Forrester содержится оценка нашего размещенного частного облака и наших предложений Baremetal.

Мы считаем, что оценка функций продукта Forrester указывает на то, что OVHcloud предоставляет мощный технологический стек, получивший наивысшие возможные баллы по критерию разрешений, ролей и библиотеки изображений, который определяется как наличие убедительных доказательств ролевого контроля доступа и интеграции с каталогом. Сервисы. Наши хранилища получили наивысший балл по критерию вариантов хранения.

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

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

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

Четкое видение будущего рынка размещенного частного облака

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

Наши решения OVHcloud Hosted Private Cloud основаны на ведущих решениях на рынке  (OVHcloud — проверенный поставщик облачных услуг VMware) и  основаны на  новейших аппаратных  технологиях (OVHcloud проектирует и создает собственные серверы и центры обработки данных).

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

Например, в отношении  возможностей хранилища , ключевого требования для клиентов облачных сред и основного кирпича нашего предложения, OVHcloud предлагает полный спектр вариантов от NFS до полнофункционального гиперконвергентного хранилища NVMe с технологией vSAN, которая также демонстрирует лучшее соотношение цены и производительности, наблюдаемое на рынок. 

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

Строим будущее вместе с экосистемой OVHcloud

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

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

OVHcloud запустит в 2020 году более  широкий спектр продуктов для размещенных частных облаков  — от экономичных до частных облаков корпоративного уровня. OVHcloud также работает над новыми предложениями для клиентов, которым требуются  выделенные зоны  для решения проблем, связанных с защитой данных, нормативными требованиями или суверенитетом.

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

Вы хотите знать больше?

Если вы хотите получить более подробную информацию о службах размещенного частного облака OVHcloud и загрузить анализ Forrester Wave ™, щелкните здесь.

Пару месяцев назад, через год после того, как наша служба Managed Kubernetes стала общедоступной, мы запустили службу Managed Private Registry. В предыдущем сообщении в блоге мы рассказали, почему решили основать его на проекте CNCF Harbour. Два сотрудника OVHcloud стали сопровождающими проекта. Теперь у нас есть новое событие, которое нужно отпраздновать: Фонд облачных вычислений только что объявил, что Харбор присоединился к очень ограниченному списку «завершенных» проектов.

Выпуск CNCF: высший уровень зрелости

CNCF размещает несколько десятков проектов с открытым исходным кодом и отлично справляется со своей работой, предлагая этим проектам поддержку роста как с точки зрения инфраструктуры и инструментов, так и с точки зрения сообщества и осведомленности. Однако большинство этих проектов находятся в «песочнице CNCF» или на стадии «инкубации». В настоящее время «завершили» только 11 проектов, включая Kubernetes, Prometheus и Helm. Харбор стал последним, кто получил этот большой знак признания.



Каждый уровень отражает выполнение очень специфических характеристик зрелости, которые соблюдаются и проверяются Комитетом технического надзора CNCF. Например, для выпуска Харбор продемонстрировал, что у него есть активные коммиттеры из нескольких организаций. Он прошел исчерпывающий и независимый аудит безопасности и имеет полностью прозрачное управление. Харбор также получил значок CII за лучшие практики.

OVHcloud с гордостью демократизирует гавань

Многие организации корпоративного уровня уже приняли Harbour как часть коммерческих платформ для контейнеризации. Обычно они развертывают и используют его локально или в облаке. Если скептики и хотели получить последний знак для принятия Harbour, он пришел… и OVHcloud очень гордится тем, что помогает сделать Harbour еще проще!

Благодаря нашей полностью управляемой службе любой пользователь OVHcloud может воспользоваться выделенной, высокодоступной и полнофункциональной гаванью. Мы предлагаем полностью предсказуемые затраты и функции корпоративного уровня, которых нет во многих облачных реестрах на рынке. Те, кто еще не готовы к использованию облака, также получат выгоду от нашего пожертвования того, что стало официальным оператором Harbour Kubernetes, чтобы облегчить самостоятельное развертывание и жизненный цикл в определенных средах.

Больше для наших нынешних и будущих пользователей управляемого реестра!

Поскольку мы хотим, чтобы вы праздновали вместе с нами, мы объявляем сегодня о еще более щедрых планах для нашего управляемого частного реестра:

• план «M», идеальный для средних компаний-разработчиков программного обеспечения или бизнес-единиц в крупных организациях; теперь включает сканирование уязвимостей
• план «L» теперь может содержать до 5 ТБ ваших артефактов (слои контейнера, диаграммы Helm и т. д.)

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

В настоящее время демонстрируя очень стабильную версию Harbour 1.10, наша контейнерная команда уже планирует перейти на Harbour 2.0.

До встречи на саммите Kubecon Europe и OVHcloud в конце этого года!

Вступление

Меня зовут Филип Дорош. Я работаю в OVHcloud с 2017 года инженером DevOps. Сегодня я хочу рассказать вам историю о том, как мы развернули Ceph следующего поколения в OVHcloud. Но сначала несколько слов о Ceph: Ceph — это программно определяемое решение для хранения данных, которое поддерживает дополнительные тома публичного облака OVHcloud, а также наш продукт Cloud Disk Array. Но я не буду утомлять вас маркетинговыми вещами — давайте начнем!

Похоже, это интересная задача ...

Полтора года назад мы начали очень знакомый спринт. Помимо обычных вещей, с которыми нам приходится иметь дело, была одна задача, которая выглядела немного интереснее. Заголовок гласил: « Оцените, можем ли мы запускать новые версии Ceph на нашем текущем программном обеспечении ». Нам нужны были более новые версии Ceph и Bluestore для создания решения Ceph следующего поколения со всеми флеш-хранилищами.

Наше программное решение (которое мы называем устаревшим решением) основано на Docker. Звучит действительно круто, но мы запускаем Docker немного иначе, чем по назначению. Наши контейнеры очень сохраняют состояние. Мы запускаем полноценную систему инициализации внутри контейнера в качестве точки входа в докер. Затем эта система инициализации запускает все необходимое программное обеспечение внутри контейнера, включая Puppet, который мы используем для управления «вещами». Похоже, мы используем контейнеры Docker так же, как контейнеры LXC, не так ли?…



Вскоре выяснилось, что невозможно запускать более новые выпуски Ceph в нашем внутреннем решении, потому что новые версии Ceph используют systemd, а в нашем текущем решении мы вообще не запускаем systemd — ни внутри контейнеров, ни на хозяева, которые их принимают.

Началась охота за решениями. Одна из возможностей заключалась в том, чтобы упаковать Ceph самостоятельно и избавиться от systemd, но это большой объем работы с небольшой добавленной стоимостью. Сообщество Ceph предоставляет проверенные пакеты, которые необходимо использовать, так что этот вариант не рассматривался.

Второй вариант — запустить Ceph с супервизором внутри контейнера Docker. Хотя это звучит как план, даже в документации supervisord четко указано, что supervisord «не предназначен для запуска вместо init как« process id 1 ».». Так что это тоже явно не вариант.

Нам нужен был systemd!

На этом этапе стало ясно, что нам нужно решение, позволяющее запускать systemd как внутри контейнера, так и на хосте. Похоже, настало идеальное время для перехода на совершенно новое решение — решение, которое было разработано для запуска полной ОС внутри контейнера. Поскольку наш Docker использовал бэкэнд LXC, это было естественным выбором для оценки LXC. В нем были все необходимые функции, но с LXC нам пришлось бы самостоятельно кодировать всю автоматизацию, связанную с контейнерами. Но можно ли избежать всей этой дополнительной работы? Оказывается, может…

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

Поэтому я переустановил свои серверы разработчиков с выпуском Ubuntu Server LTS и установил на них LXD.



LXD имеет все необходимое для создания полнофункциональных кластеров Ceph:

• он поддерживает «толстые» контейнеры с отслеживанием состояния,
• он поддерживает systemd внутри контейнера,
• он поддерживает образы контейнеров, поэтому мы можем подготовить индивидуальные изображения и без проблем использовать их,
• передача целых блочных устройств в контейнеры,
• передача обычных каталогов в контейнеры,
• поддержка простого запуска, остановки, перезапуска контейнера,
• REST API, который будет рассмотрен в следующих частях статьи,
• поддержка нескольких сетевых интерфейсов в контейнерах с использованием macvlan.

После нескольких часов ручной работы у меня был кластер Ceph, на котором запущен выпуск Mimic внутри контейнеров LXD. Я набрал ceph health и получил «HEALTH_OK». Приятно! Это сработало отлично.

Как нам это индустриализировать?

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

Демон LXD предоставляет удобный REST API, который мы использовали для создания нашего модуля Puppet. Вы можете общаться с API локально через сокет unix и через сеть, если вы настроили его раскрытие. Для использования в модуле было действительно удобно использовать команду запроса lxc, которая работает, отправляя необработанные запросы в LXD через сокет unix. Модуль теперь имеет открытый исходный код на GitHub, поэтому вы можете скачать его и поиграть с ним. Он позволяет настраивать основные параметры LXD, а также создавать контейнеры, профили, пулы хранения и т. Д.

Модуль позволяет создавать, а также управлять состоянием ресурсов. Просто измените свои манифесты, запустите марионеточный агент, и он сделает все остальное.



Модуль LXD Puppet на момент написания этого документа предоставляет следующие определения:

• lxd :: profile
• lxd :: изображение
• lxd :: хранилище
• lxd :: container

Для получения полной справки посетите его страницу GitHub — github.com/ovh/lxd-puppet-module.

Ручная установка VS Автоматическая установка с Puppet

Я покажу вам простой пример того, как создать точно такую ​​же настройку вручную, а затем снова автоматически с помощью Puppet. Для целей этой статьи я создал новый экземпляр Public Cloud с Ubuntu 18.04, один дополнительный диск и уже настроенное мостовое устройство br0. Предположим, есть также DHCP-сервер, прослушивающий интерфейс br0.

Стоит отметить, что обычно вам не нужно создавать собственное изображение, вы можете просто использовать вышестоящие со встроенными командами. Но для целей этой статьи давайте создадим собственный образ, который будет в точности похож на исходный. Чтобы создать такой образ, вам просто нужно ввести несколько команд, чтобы перепаковать исходный образ в Unified Tarball.

root @ ubuntu: ~ # wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64-root.tar.xz 
root @ ubuntu: ~ # wget https: // cloud-images .ubuntu.com / bionic / current / bionic-server-cloudimg-amd64-lxd.tar.xz 
root @ ubuntu: ~ # mkdir -p ubuntu1804 / rootfs 
root @ ubuntu: ~ # tar -xf bionic-server-cloudimg-amd64 -lxd.tar.xz -C ubuntu1804 / 
root @ ubuntu: ~ # tar -xf bionic-server-cloudimg-amd64-root.tar.xz -C ubuntu1804 / rootfs / 
root @ ubuntu: ~ # cd ubuntu1804 / 
root @ ubuntu : ~ / ubuntu1804 # tar -czf ../ubuntu1804.tar.gz *

В конце вы получите образ ubuntu1804.tar.gz, который можно использовать с LXD. Для целей этой статьи я поместил это изображение в каталог, доступный через HTTP, например: example.net/lxd-image/

Ручная настройка

Первым делом давайте установим LXD.

root @ ubuntu: ~ # apt install lxd

Во время установки пакета вы увидите сообщение: «Чтобы пройти начальную конфигурацию LXD, запустите: lxd init», но мы просто сделаем все шаги вручную.

Следующим шагом будет добавление нового пула хранения.

root @ ubuntu: ~ # lxc storage create default dir source = / var / lib / lxd / storage-pools / 
default Создание пула хранения по умолчанию

Затем создайте собственный профиль, который будет иметь: переменную окружения http_proxy, установленную на ”, ограничение памяти 2 ГБ, крыши в пуле хранения по умолчанию и eth0, который будет частью моста br0.

root@ubuntu:~# lxc profile create customprofile
Profile customprofile created
root@ubuntu:~# lxc profile device add customprofile root disk path=/ pool=default
Device root added to customprofile
root@ubuntu:~# lxc profile device add customprofile eth0 nic nictype=bridged parent=br0
Device eth0 added to customprofile
root@ubuntu:~# lxc profile set customprofile limits.memory 2GB

Распечатываем весь профиль, чтобы проверить, все ли в порядке:

root@ubuntu:~# lxc profile show customprofile
config:
  environment.http_proxy: ""
  limits.memory: 2GB
description: ""
devices:
  eth0:
    nictype: bridged
    parent: br0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: customprofile
used_by: []

Затем давайте загрузим изображение LXD в формате Unified Tarball:

root@ubuntu:~# wget -O /tmp/ubuntu1804.tar.gz http://example.net/lxd-images/ubuntu1804.tar.gz

И импортируйте его:

root@ubuntu:~# lxc image import /tmp/ubuntu1804.tar.gz --alias ubuntu1804
Image imported with fingerprint: dc6f4c678e68cfd4d166afbaddf5287b65d2327659a6d51264ee05774c819e70

Когда все будет готово, давайте создадим наш первый контейнер:

root@ubuntu:~# lxc init ubuntu1804 container01 --profile customprofile
Creating container01

Теперь давайте добавим несколько каталогов хоста в контейнер:
обратите внимание, что вы должны установить правильного владельца каталога на хосте!

root@ubuntu:~# mkdir /srv/log01
root@ubuntu:~# lxc config device add container01 log disk source=/srv/log01 path=/var/log/

И в качестве последнего штриха добавьте в контейнер раздел хоста:

root@ubuntu:~# lxc config device add container01 bluestore unix-block source=/dev/sdb1 path=/dev/bluestore

/ dev / sdb1 будет доступен внутри контейнера. Мы используем его для передачи устройств для Ceph's Bluestore в контейнер.

Контейнер готов к запуску.

root@ubuntu:~# lxc start container01

Вуаля! Контейнер запущен и работает. Мы настраиваем наши контейнеры так же, как указано выше.

Хотя это было довольно просто настроить вручную. Для массового развертывания вам необходимо автоматизировать вещи. Итак, теперь давайте сделаем это, используя наш модуль LXD Puppet.

Автоматическая установка с Puppet

Чтобы использовать модуль, загрузите его на свой марионеточный сервер и поместите в путь к модулю.

Затем создайте новый класс или добавьте его к одному из существующих классов; все, что вам подходит.



Я подключил его к своему марионеточному серверу. Обратите внимание, что я использую мостовое устройство br0, которое было подготовлено ранее другими модулями, и что изображения LXD размещаются на веб-сервере example.net/lxd-images/ в виде унифицированных тарболов.

Полный пример модуля, использующего модуль LXD Puppet:

class mymodule { 
 
    class {':: lxd':} 
 
    lxd :: storage {'default': 
        driver => 'dir', 
        config => { 
            'source' => '/ var / lib / lxd / storage-pools / default ' 
        } 
    } 
 
    lxd :: profile {' exampleprofile ': sure 
        =>' present ', 
        config => { 
            ' environment.http_proxy '=>' ', 
            ' limits.memory '=>' 2GB ', 
        }, 
        devices => { 
            'root' => { 
                'path' => '/', 
                'pool' => 'default',
                'type' => 'disk', 
            }, 
            'eth0' => {
                'nictype' => 'bridged', 
                'parent' => 'br0', 
                'type' => 'nic', 
            } 
        } 
    } 
 
    lxd :: image {'ubuntu1804': sure 
        => 'present', 
        repo_url => ' http://example.net/lxd-images/ ', 
        image_file =>' ubuntu1804.tar.gz ', 
        image_alias =>' ubuntu1804 ', 
    } 
 
    lxd :: container {' container01 ': 
        state =>' start ', 
        config => { 
            'user.somecustomconfig' => 'Моя потрясающая пользовательская переменная env',
        }, 
        profiles => ['exampleprofile'], 
        image => 'ubuntu1804',
        устройства => { 
            'log' => { 
                'path' => '/ var / log /', 
                'source' => '/ srv / log01', 
                'type' => 'disk', 
            }, 
            'bluestore' = > { 
                'путь' => '/ dev / bluestore', 
                'source' => '/ dev / sdb1', 
                'type' => 'unix-block', 
            } 
        } 
    } 
}

Теперь осталось только запустить марионеточный агент на машине. Он применит желаемое состояние:

root@ubuntu:~# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for ubuntu.openstacklocal
Info: Applying configuration version '1588767214'
Notice: /Stage[main]/Lxd::Install/Package[lxd]/ensure: created
Notice: /Stage[main]/Lxd::Config/Lxd_config[global_images.auto_update_interval]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Storage[default]/Lxd_storage[default]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Profile[exampleprofile]/Lxd_profile[exampleprofile]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Image[ubuntu1804]/Exec[lxd image present http://example.net/lxd-images//ubuntu1804.tar.gz]/returns: executed successfully
Notice: /Stage[main]/Mymodule/Lxd::Container[container01]/Lxd_container[container01]/ensure: created
Notice: Applied catalog in 37.56 seconds

В конце концов, у вас будет запущен новый контейнер:

root@ubuntu:~# lxc ls
+-------------+---------+--------------------+------+------------+-----------+
|    NAME     |  STATE  |        IPV4        | IPV6 |    TYPE    | SNAPSHOTS |
+-------------+---------+--------------------+------+------------+-----------+
| container01 | RUNNING | 192.168.0.5 (eth0) |      | PERSISTENT | 0         |
+-------------+---------+--------------------+------+------------+-----------+

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



Как это хорошо !?

Я призываю всех внести свой вклад в модуль или поставить ему звезду на GitHub, если вы сочтете его полезным.

Планы на будущее

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

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