Что такое IPMI? Какова цель IPMI? Зачем мне нужен IPMI? Все это справедливые вопросы. В мире хостинг-провайдеров IPMI или (интерфейс интеллектуального управления платформой) используется почти так же, как «SDDC (программно-определяемый центр обработки данных)» или «IaaS (инфраструктура как услуга)», но что это означает и почему вы должны забота?

IPMI был создан в результате сотрудничества между Intel, Dell, Hewlett Packard и NEC. С момента своего создания он стал отраслевым стандартом как важное аппаратное решение, которое позволяет администраторам серверов отслеживать состояние оборудования, регистрировать данные сервера и разрешать доступ к серверу без физического доступа к серверу. Получая доступ к серверу через IPMI, вам предоставляется доступ к BIOS системы, наличие этого доступа позволяет вам установить или переустановить вашу собственную операционную систему, исправить любые ошибки в конфигурации сети или повторно включить доступ по SSH или RDP с помощью KVM (Keyboard Video Mouse) доступ к сервер.



Используя инфраструктуру OVHcloud®, вы сможете использовать IPMI и получить доступ к BIOS вашего сервера. Это позволяет вам быть эффективным администратором сервера и устранять любые проблемы, которые могут возникнуть с вашим сервером, а также устанавливать любую операционную систему, совместимую с компонентами вашего сервера.

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

Чтобы узнать больше о том, как получить доступ к IPMI из OVHcloud Manager и как установить операционную систему, использующую IPMI, обратитесь к следующим руководствам, которые шаг за шагом проведут вас через процесс: Начало работы с IPMI, Как установить ОС с IPMI.

Абстрактно

Мне как исследователю необходимо проводить эксперименты, чтобы подтвердить свои гипотезы. Когда речь идет о компьютерных науках, хорошо известно, что специалисты-практики обычно проводят эксперименты в различных средах (на аппаратном уровне: x86 / arm /…, частота процессора, доступная память или на уровне программного обеспечения: операционная система, версии библиотек). Проблема с этими различными средами заключается в сложности точного воспроизведения эксперимента, как он был представлен в исследовательской статье.

В этом посте мы предлагаем способ проведения экспериментов, который можно воспроизвести с помощью Kubernetes-as-a-service, управляемой платформы для выполнения распределенных вычислений вместе с другими инструментами (Argo, MinIO), которые учитывают преимущества платформы.



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

Вступление

Когда я начал свою докторскую диссертацию, я прочитал кучу статей, относящихся к той области, в которой я работаю, то есть к AutoML. Из этого исследования я понял, насколько важно хорошо проводить эксперименты, чтобы они были достоверными и проверяемыми. Я начал спрашивать своих коллег, как они проводят свои эксперименты, и у них был общий шаблон: разработайте свое решение, посмотрите на другие решения, связанные с той же проблемой, запустите каждое решение 30 раз, если оно стохастическое. с эквивалентными ресурсами и сравните свои результаты с другими решениями с помощью статистических тестов: Вилкоксона-Манна-Уитни при сравнении двух алгоритмов или теста Фридмана. Поскольку это не основная тема данной статьи, я не буду подробно останавливаться на статистических тестах.

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

Либо вам повезло и исходный код доступен, либо в публикации указан псевдокод. В этом случае вам необходимо повторно реализовать решение, чтобы можно было его протестировать и сравнить. Даже если вам повезло и есть доступный исходный код, часто отсутствует вся среда (например, точная версия пакетов, сама версия python, версия JDK и т. Д.…). Отсутствие нужной информации влияет на производительность и может потенциально искажать эксперименты. Например, новые версии пакетов, языков и т. Д. Обычно имеют лучшую оптимизацию, которую может использовать ваша реализация. Иногда бывает сложно найти версии, которые использовались практикующими.

Другая проблема — сложность настройки кластера с помощью программного обеспечения HPC (например, Slurm, Torque). Действительно, для управления таким решением требуются технические знания: настройка сети, проверка того, что каждый узел имеет зависимости, необходимые для установленных запусков, проверка того, что узлы имеют одинаковые версии библиотек и т. Д. Эти технические шаги отнимают время у исследователей, таким образом отвлеките их от основной работы. Более того, чтобы извлечь результаты, исследователи обычно делают это вручную, они извлекают различные файлы (через FTP или NFS), а затем выполняют статистические тесты, которые сохраняют вручную. Следовательно, рабочий процесс проведения эксперимента относительно дорог и ненадежен.

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

Решение

OVH предлагает Kubernetes-as-a-service, платформу управляемого кластера, где вам не нужно беспокоиться о том, как настроить кластер (добавить узел, настроить сеть и т. Д.), Поэтому я начал исследовать, как я мог бы аналогичным образом проводить эксперименты. к решениям для высокопроизводительных вычислений. Argo Workflows вышла из коробки. Этот инструмент позволяет вам определять рабочий процесс шагов, которые вы можете выполнять в своем кластере Kubernetes, когда каждый шаг заключен в контейнер, который в общих чертах называется образом. Контейнер позволяет запускать программу в определенной среде программного обеспечения (языковая версия, библиотеки, сторонние программы), дополнительно ограничивая ресурсы (время процессора, память), используемые программой.

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

Пример использования: оценка решения AutoML

Вариант использования, который мы используем в нашем исследовании, будет связан с измерением сходимости байесовской оптимизации (SMAC) по проблеме AutoML.

Для этого варианта использования мы указали рабочий процесс Argo в следующем файле yaml

Настроить инфраструктуру

Сначала мы настроим кластер Kubernetes, во-вторых, мы установим службы в нашем кластере и, наконец, проведем эксперимент.

Кластер Kubernetes

Установка кластера Kubernetes с OVH — это детская игра. Подключитесь к панели управления OVH, перейдите к Public Cloud > Managed Kubernetes Service, затем Create a Kubernetes clusterследуйте инструкциям в зависимости от ваших потребностей.

• После создания кластера:
  
  • Примите во внимание политику обновления изменений. Если вы исследователь и для выполнения вашего эксперимента требуется некоторое время, вам следует избегать обновления, которое отключило бы вашу инфраструктуру во время выполнения. Чтобы избежать такой ситуации, лучше выбрать «Минимальная недоступность» или «Не обновлять».
  • Загрузите 

    kubeconfig

    файл, он будет использоваться позже 

    kubectl

    для подключения к нашему кластеру.
  • Добавьте хотя бы один узел в свой кластер.
После установки вам понадобится kubectl  — инструмент, позволяющий управлять кластером.Если все настроено правильно, должно получиться примерно следующее:

kubectl top nodes
NAME      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node01   64m          3%     594Mi           11%

Установка Арго

Как мы упоминали ранее, Argo позволяет нам запускать рабочий процесс, состоящий из шагов. Этот учебник вдохновил нас на установку клиента и службы в кластере.Сначала скачиваем и устанавливаем Арго (клиент):

curl -sSL -o /usr/local/bin/argo https://github.com/argoproj/argo/releases/download/v2.3.0/argo-linux-amd64
chmod +x /usr/local/bin/argo

Настройте учетную запись службы:

kubectl create rolebinding default-admin --clusterrole=admin --serviceaccount=default:default

Затем с клиентом попробуйте простой рабочий процесс hello-world, чтобы убедиться, что стек работает (статус: успешно):

argo submit --watch https://raw.githubusercontent.com/argoproj/argo/master/examples/hello-world.yaml
Name:                hello-world-2lx9d
Namespace:           default
ServiceAccount:      default
Status:              Succeeded
Created:             Tue Aug 13 16:51:32 +0200 (24 seconds ago)
Started:             Tue Aug 13 16:51:32 +0200 (24 seconds ago)
Finished:            Tue Aug 13 16:51:56 +0200 (now)
Duration:            24 seconds

STEP                  PODNAME            DURATION  MESSAGE
 ✔ hello-world-2lx9d  hello-world-2lx9d  23s

Вы также можете получить доступ к панели управления пользовательского интерфейса через localhost:8001:



kubectl port-forward -n argo service/argo-ui 8001:80

Настроить репозиторий артефактов (MinIO)

Артефакт — это термин, используемый Argo, он представляет собой архив, содержащий файлы, возвращаемые шагом. В нашем случае мы будем использовать эту функцию, чтобы возвращать окончательные результаты и делиться промежуточными результатами между шагами.Чтобы Artifact работал, нам нужно хранилище объектов. Если он у вас уже есть, вы можете пропустить часть установки, но все равно нужно его настроить.Как указано в руководстве, мы использовали MinIO, вот манифест для его установки ( minio-argo-artifact.install.yml):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  # This name uniquely identifies the PVC. Will be used in deployment below.
  name: minio-pv-claim
  labels:
    app: minio-storage-claim
spec:
  # Read more about access modes here: https://kubernetes.io/docs/user-guide/persistent-volumes/#access-modes
  accessModes:
    - ReadWriteOnce
  resources:
    # This is the request for storage. Should be available in the cluster.
    requests:
      storage: 10
  # Uncomment and add storageClass specific to your requirements below. Read more https://kubernetes.io/docs/concepts/storage/persistent-volumes/#class-1
  #storageClassName:
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  # This name uniquely identifies the Deployment
  name: minio-deployment
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        # Label is used as selector in the service.
        app: minio
    spec:
      # Refer to the PVC created earlier
      volumes:
      - name: storage
        persistentVolumeClaim:
          # Name of the PVC created earlier
          claimName: minio-pv-claim
      containers:
      - name: minio
        # Pulls the default MinIO image from Docker Hub
        image: minio/minio
        args:
        - server
        - /storage
        env:
        # MinIO access key and secret key
        - name: MINIO_ACCESS_KEY
          value: "TemporaryAccessKey"
        - name: MINIO_SECRET_KEY
          value: "TemporarySecretKey"
        ports:
        - containerPort: 9000
        # Mount the volume into the pod
        volumeMounts:
        - name: storage # must match the volume name, above
          mountPath: "/storage"
---
apiVersion: v1
kind: Service
metadata:
  name: minio-service
spec:
  ports:
    - port: 9000
      targetPort: 9000
      protocol: TCP
  selector:
    app: minio

• Примечание . Измените следующие пары «ключ-значение»:
  

  • spec > resources > requests > storage > 10

     соответствуют 10 ГБ хранилища, запрошенного MinIO для кластера

  • TemporaryAccessKey

  • TemporarySecretKey

kubectl create ns minio
kubectl apply -n minio -f minio-argo-artifact.install.yml

Примечание: в качестве альтернативы вы можете установить MinIO с Helm.Теперь нам нужно настроить Argo, чтобы использовать наше хранилище объектов MinIO:

kubectl edit cm -n argo workflow-controller-configmap
...
data:
  config: |
    artifactRepository:
      s3:
        bucket: my-bucket
        endpoint: minio-service.minio:9000
        insecure: true
        # accessKeySecret and secretKeySecret are secret selectors.
        # It references the k8s secret named 'argo-artifacts'
        # which was created during the minio helm install. The keys,
        # 'accesskey' and 'secretkey', inside that secret are where the
        # actual minio credentials are stored.
        accessKeySecret:
          name: argo-artifacts
          key: accesskey
        secretKeySecret:
          name: argo-artifacts
          key: secretkey

Добавьте учетные данные:

kubectl create secret generic argo-artifacts --from-literal=accesskey="TemporaryAccessKey" --from-literal=secretkey="TemporarySecretKey"

Примечание. Используйте правильные учетные данные, указанные выше.Создайте ведро my-bucketс правами Read and writeподключившись к интерфейсу localhost:9000:



kubectl port-forward -n minio service/minio-service 9000

Убедитесь, что Argo может использовать Artifact с хранилищем объектов:

argo submit --watch https://raw.githubusercontent.com/argoproj/argo/master/examples/artifact-passing.yaml
Name:                artifact-passing-qzgxj
Namespace:           default
ServiceAccount:      default
Status:              Succeeded
Created:             Wed Aug 14 15:36:03 +0200 (13 seconds ago)
Started:             Wed Aug 14 15:36:03 +0200 (13 seconds ago)
Finished:            Wed Aug 14 15:36:16 +0200 (now)
Duration:            13 seconds

STEP                       PODNAME                            DURATION  MESSAGE
 ✔ artifact-passing-qzgxj
 ├---✔ generate-artifact   artifact-passing-qzgxj-4183565942  5s
 └---✔ consume-artifact    artifact-passing-qzgxj-3706021078  7s

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

Установить частный реестр

Теперь, когда у нас есть способ запустить рабочий процесс, мы хотим, чтобы каждый шаг представлял конкретную программную среду (то есть изображение). Мы определили эту среду в Dockerfile.Поскольку каждый шаг может выполняться на разных узлах в нашем кластере, образ необходимо где-то хранить, в случае Docker нам требуется частный реестр.Получить приватный реестр можно разными способами:
• Докер Хаб
• Gitlab.com
• OVH - учебник
• Harbour : позволяет иметь собственный реестр в кластере Kubernetes.
В нашем случае мы использовали частный реестр OVH.

# First we clone the repository
git clone git@gitlab.com:automl/automl-smac-vanilla.git
cd automl-smac-vanilla

# We build the image locally
docker build -t asv-environment:latest .

# We push the image to our private registry
docker login REGISTRY_SERVER -u REGISTRY_USERNAME
docker tag asv-environment:latest REGISTRY_IMAGE_PATH:latest
docker push REGISTRY_IMAGE_PATH:latest

Разрешите нашему кластеру извлекать образы из реестра:

kubectl create secret docker-registry docker-credentials --docker-server=REGISTRY_SERVER --docker-username=REGISTRY_USERNAME --docker-password=REGISTRY_PWD

Попробуйте наш эксперимент на инфраструктуре

git clone git@gitlab.com:automl/automl-smac-vanilla.git
cd automl-smac-vanilla

argo submit --watch misc/workflow-argo -p image=REGISTRY_IMAGE_PATH:latest -p git_ref=master -p dataset=iris
Name:                automl-benchmark-xlbbg
Namespace:           default
ServiceAccount:      default
Status:              Succeeded
Created:             Tue Aug 20 12:25:40 +0000 (13 minutes ago)
Started:             Tue Aug 20 12:25:40 +0000 (13 minutes ago)
Finished:            Tue Aug 20 12:39:29 +0000 (now)
Duration:            13 minutes 49 seconds
Parameters:
  image:             m1uuklj3.gra5.container-registry.ovh.net/automl/asv-environment:latest
  dataset:           iris
  git_ref:           master
  cutoff_time:       300
  number_of_evaluations: 100
  train_size_ratio:  0.75
  number_of_candidates_per_group: 10

STEP                       PODNAME                            DURATION  MESSAGE
 ✔ automl-benchmark-xlbbg
 ├---✔ pre-run             automl-benchmark-xlbbg-692822110   2m
 ├-·-✔ run(0:42)           automl-benchmark-xlbbg-1485809288  11m
 | └-✔ run(1:24)           automl-benchmark-xlbbg-2740257143  9m
 ├---✔ merge               automl-benchmark-xlbbg-232293281   9s
 └---✔ plot                automl-benchmark-xlbbg-1373531915  10s

Примечание :
• Здесь у нас всего 2 параллельных прогона, вы можете получить гораздо больше, добавив их в список 

  withItems

   . В нашем случае список соответствует семенам.

• run(1:24)

  соответствуют пробегу 

  1

  с семенами

  24

• Мы ограничиваем ресурсы на запуск, используя запросы и ограничения , см. Также Управление вычислительными ресурсами .
Затем мы просто получаем результаты через веб-интерфейс пользователя MinIO localhost:9000(вы также можете сделать это с помощью клиента ).

Результаты находятся в каталоге с тем же именем, что и имя рабочего процесса argo, в нашем примере это так my-bucket > automl-benchmark-xlbbg.



Ограничение нашего решения

Решение не может выполнять параллельные шаги на нескольких узлах. Это ограничение связано с тем, как мы объединяем наши результаты от параллельных шагов к шагу слияния. Мы используем volumeClaimTemplates, то есть монтируем том, и это невозможно сделать между разными узлами. Проблему можно решить двумя способами:
• Использование параллельных артефактов и их агрегирование, однако это постоянная проблема с Argo
• Непосредственно реализовать в коде вашего запуска способ сохранить результат в доступном хранилище (например, MinIO SDK )
Первый способ предпочтительнее, это означает, что вам не нужно изменять и настраивать код для конкретной файловой системы хранилища.

Советы по улучшению решения

Если вы хотите продолжить настройку, вам следует изучить следующие темы:
• Контроль доступа : чтобы ограничить пользователей в разных пространствах (по соображениям безопасности или для контроля ресурсов).
• Исследуя селектор Арго и селектор Kubernetes : в случае , если у вас есть кластер состоит из узлов , которые имеют различное оборудование , и что вам требуется эксперимент с использованием конкретного оборудования (например, конкретный процессор, графический процессор).
• Настройте распределенный MinIO : он гарантирует, что ваши данные будут реплицированы на несколько узлов и останутся доступными в случае отказа узла.
• Мониторинг вашего кластера .

Вывод

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

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



Совместное исследование в OVH через диссертацию

Тезис CIFRE означает на французском языке « Convention Industrielle de Formation par la Recherche», буквально « Промышленная конвенция для обучения через исследования». Цель состоит в том, чтобы поощрять исследовательское сотрудничество между частными и государственными организациями. Для предпринимателей и аспирантов CIFRE — это средство обучения посредством исследований и приобретения серьезных научных знаний. Для ученых это средство управления новым кандидатом наук и применения результатов исследований в экономическом кейсе. ANRT ассоциация управления CIFRE диссертацию.

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

AutoML, как пример тезиса AI

настройки конвейеров машинного обучения ». MO расшифровывается как Multi-Objective и AutoML для автоматизированного машинного обучения.

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

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

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

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

OVH и AI

Конечно, тезис AutoML будет иметь множество последствий для OVH. С этого момента наша работа над машинным обучением позволила нам запустить Prescience в наших лабораториях. Prescience — это распределенная и масштабируемая платформа, которая позволяет пользователю создавать, развертывать и запрашивать модели машинного обучения.

В результате тесного сотрудничества с частным партнером NVIDIA, OVH предоставляет программную платформу NVIDIA GPU Cloud (NGC) в качестве эксклюзивного европейского продукта. Целью этого партнерства является облегчение доступа к искусственному интеллекту, позволяя пользователям запускать свою обработку через NGC на продуктах NVIDIA, размещенных в инфраструктуре OVH.

В OVH наша первая задача как поставщика облачных услуг — предоставлять продукты с высоким качеством обслуживания (QoS). Будь то выделенные серверы, облачные серверы или размещенные веб-сайты, наши клиенты ожидают от наших решений очень высокого качества. И это именно то, что наши команды стараются предложить вам ежедневно!

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

Итак, как мы можем количественно оценить это качество обслуживания? Как мы понимаем качество, обеспечиваемое каждым продуктом каждый день, с максимальной точностью?

Первым шагом было найти существующие инструменты, но мы быстро поняли, что ни одно решение не отвечает нашим требованиям. Основываясь на этом наблюдении, мы решили разработать собственное решение для вычисления QoS: DepC. Первоначально созданная для команды WebHosting, эта платформа быстро распространилась по OVH. Сейчас он используется внутри компании десятками команд.

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

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

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

Что такое QoS?

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

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

QoS выражается в процентах, начиная со 100%, когда обслуживание выполняется идеально, а затем постепенно уменьшается в случае сбоя. Этот процент должен быть связан с периодом: месяц, день, время и т. Д. Таким образом, сервис может иметь 99,995% QoS в текущий день, тогда как накануне оно было 100%.

Важны и другие концепции:

• SLA (соглашение об уровне обслуживания) : не путать с QoS, это договор между заказчиком и поставщиком, указывающий на ожидаемое качество обслуживания. Этот контракт может включать штрафы, предоставленные заказчику в случае невыполнения целей.
• SLO (цель уровня обслуживания) : это относится к цели, которую поставщик услуг хочет достичь с точки зрения QoS.
• SLI (индикатор уровня обслуживания) : это мера (время отклика ping, код состояния HTTP, задержка сети ...), используемая для оценки качества обслуживания. SLI лежат в основе DepC, поскольку они позволяют нам преобразовывать необработанные данные в QoS.

Цели

DepC изначально был создан для команды WebHosting. 5 миллионов веб-сайтов, распределенных на более чем 14 000 серверов, инфраструктура, необходимая для работы веб-сайтов (описанная в этой статье ), а также постоянные изменения затрудняют расчет качества обслуживания в реальном времени для каждого из наших клиентов.. Кроме того, чтобы идентифицировать проблему в прошлом, нам также нужно было знать, как восстановить QoS, чтобы отразить состояние инфраструктуры в то время.

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

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

• Команда WebHosting управляет миллионами веб-сайтов, поэтому масштабирование было бы очень трудным.
• Мы не единственные гаранты правильного функционирования веб-сайтов. Это также зависит от клиента, который может (намеренно или нет) генерировать ошибки, которые будут интерпретированы как ложные срабатывания.
• Даже если бы мы решили предыдущие трудности и можно было бы рассчитать QoS веб-сайтов, было бы невозможно определить первопричины в случае сбоя.

Нам нужно было найти другое решение…

График зависимостей

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

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

1. Исходный код ваших веб-сайтов размещен на серверах хранения (называемых filerz ).
2. Базы данных, используемые сайтом, также размещены на серверах баз данных .

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



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

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

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

Однако создание дерева зависимостей (узлов и их отношений) не требует от нас знания Neo4j, потому что мы разработали демон, который позволяет нам преобразовывать сообщения JSON в узлы на графе. DepC предоставляет API, так что каждая команда может добавлять новые элементы в свое дерево зависимостей, не изучая Cypher.

Принцип такой:

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

Поскольку DepC доступен на Github, документация по этой части доступна в этом руководстве.

Расчет QoS

Платформа DepC предлагает API для хранения и запроса дерева зависимостей. Это может показаться тривиальным, но постоянное наблюдение за инфраструктурой — уже сложная задача. Это настолько мощно, что некоторые команды используют только эту часть платформы, используя DepC как эквивалент своей CMDB (инвентаризация своего технического парка).

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

• Узел представляет собой элемент, контролируемый одним или несколькими датчиками.
• Целевой узел не является контролируемым элементом

Контролируемые узлы

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

Здесь мы находим концепцию SLI, которую мы видели выше: DepC анализирует необработанные данные, отправленные зондами, чтобы преобразовать их в QoS.

Принцип очень простой:

• Пользователи объявляют индикаторы в DepC, определяя запрос на получение данных из базы данных временных рядов, а также порог, который подразумевает снижение QoS для этого узла.
• DepC запускает этот запрос для всех узлов, выбранных пользователем, затем каждый результат анализируется, чтобы вычислить QoS, как только пороговое значение будет превышено. Затем мы получаем QoS данного узла. Обратите внимание, что этот процесс выполняется каждую ночь благодаря инструменту планирования задач Airflow .

Технически анализ временных рядов DepC — это просто преобразование отсортированного по времени списка значений в отсортированный по времени список логических значений.



В этом случае расчет очень прост: значение «истина» увеличит QoS, а значение «ложь» - снизит его. Например, из 100 точек, когда 95 баллов ниже порогового значения ( верно ), QoS будет 95% (DepC запускает этот расчет каждую ночь; количество точек данных на самом деле намного выше).
Обратите внимание, что для завершения этой части DepC в настоящее время поддерживает базы данных временных рядов OpenTSDB и Warp10. Скоро будут добавлены другие базы данных временных рядов (InfluxDB, Prometheus…).

Неконтролируемые узлы

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

Представьте себе, например, узел, представляющий «клиента», связанный с несколькими контролируемыми узлами типа «сервер». У нас нет данных для анализа по этому клиенту. С другой стороны, для «серверных» узлов мы можем рассчитать их QoS благодаря наблюдаемым узлам. Затем мы объединяем эти показатели QoS, чтобы получить значение «клиентского» узла.

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




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

В этом примере мы использовали только логический оператор. Однако DepC предоставляет несколько типов логических операций для разных приложений:

• И : все зависимости должны работать, чтобы услуга была предоставлена.
• ИЛИ : для оказания услуги достаточно одной зависимости.
• СООТНОШЕНИЕ (N) : необходимо, чтобы N% зависимостей работали для предоставления услуги.
• ATLEAST (N) : независимо от количества зависимостей, услуга предоставляется, если функционируют как минимум N зависимостей.

Мы не будем слишком углубляться во внутреннее функционирование, которое позволяет нам рассчитывать QoS в больших масштабах. Но если вас это интересует, я приглашаю вас посмотреть конференцию, которую мы провели на FOSDEM 2019 в Python devroom. Видео и слайды доступны по этому адресу .

Вывод

DepC уже используется десятками команд в OVH. Выбранная архитектура позволяет нам предлагать визуализацию QoS через встроенный веб-интерфейс с самим DepC или депортировать дисплей в Grafana.


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



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

Наша цель — стать стандартным решением для расчета QoS в OVH. Инструмент находится в производстве несколько месяцев, и мы получаем тысячи новых узлов в день. В нашей базе данных сейчас более 10 миллионов, и это только начало.

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

Ссылки

• Github: https://github.com/ovh/depc
• Документация: https://ovh.github.io/depc/
• Презентация FOSDEM 2019 (EN): https://fosdem.org/2019/schedule/event/python_compute_qos_of_your_infrastructure/
• Презентация PyconFR 2018 (FR): https://pyvideo.org/pycon-fr-2018/calculer-la-qos-de-vos-infrastructures-avec-asyncio.html

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

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

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

В течение следующих 12 месяцев мы запустим бренд OVHcloud, начиная с нашего заметного мероприятия OVHcloud Summit в Париже.



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

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

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

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

Сценарии

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

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

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

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

Самостоятельный перенос сайтов

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

Вот что обычно приходилось делать нашим клиентам:

• Определите все базы данных, используемые в их исходном коде
• Настройте целевую учетную запись
• Поместите сайт на обслуживание в центр обработки данных в Париже, чтобы избежать раздвоения мозгов
• Перенести все данные: файлы исходного кода, а также базы данных
• Настройте новые учетные данные базы данных в исходном коде сайта.
• Убедитесь, что сайт работает как задумано
• Измените свою зону DNS, чтобы перенаправить свой веб-сайт на новый IP-адрес нового кластера Gravelines.
• Повторно откройте сайт и дождитесь окончания задержки распространения DNS.

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

• Надежная идентификация всех используемых баз данных сложна. Можно искать все имена баз данных в исходном коде наших клиентов, но это очень долгая операция, надежная только в том случае, если исходный код не изменяется в течение этого времени. Это также требует работы со многими особыми случаями: двоичные файлы, выполняемые в CGI, обфускация исходного кода или даже хранение имени баз данных в… базе данных. Этот метод не позволяет нам рассчитывать на 100% надежность нашей миграции.
• Перенос файлов можно выполнить двумя способами:
  
  1. В файловом режиме сценарий миграции проходит по дереву файлов и копирует их по одному.
  
  
  2. В блочном режиме сценарий миграции берет данные с жесткого диска и побитно передает их на целевой жесткий диск без учета древовидной структуры.

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

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

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

• Изменение исходного кода — опасная операция, которую мы не позволяем делать, потому что это может сильно повлиять на веб-сайт. Кроме того, это требует исчерпывающего определения всех видов использования баз данных…
• Некоторые наши клиенты не размещают свою зону DNS дома. После этого мы не сможем изменить IP-адрес их веб-сайта без их вмешательства, что требует от нас сохранения этого IP-адреса, если мы хотим достичь хорошего уровня надежности для миграции.

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

IP через грузовые автомобили

Интернет основан на IP-протоколе для адресации машин в сети. Это не зависит от физического материала, на котором происходит обмен сообщениями, можно использовать многие: оптические каналы, электрические, беспроводные; даже странствующих голубей, как это описано в юмористическом стандарте, установленном 1 апреля 1990 года!

Эта первоапрельская шутка нас вдохновила, хотя мы не знатоки голубей. В самом деле, даже если задержка (продолжительность путешествия для сообщения из точки A в точку B) важна, пропускная способность (количество отправленной информации / время в пути) потенциально огромна: USB-ключ содержит много данных! При некоторых больших передачах физическое перемещение данных — разумный способ увеличить пропускную способность передачи.

Поэтому мы подумали о варианте просто перенести инфраструктуру из Парижа в Gravelines. У этого есть преимущества:

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

Но это также создает некоторые проблемы:

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

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

Масштабируемые миграции

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

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

• IP-адреса: мы не контролировали все зоны DNS, мы считали, что IP-адреса сайтов наших клиентов не могут быть изменены. Это означает, что мы должны перенести сразу все веб-сайты, использующие один и тот же IP-адрес.
• Filerz : миграция в файл данных режима на filerz не является возможным из - за большое количество файлов, мы должны выполнить миграцию в блочной режиме и тем самым перенести все клиент в том же filerz одновременно.
• Базы данных: все базы данных на одном веб-сайте должны быть перенесены одновременно, чтобы сайт продолжал работать, а идентификаторы баз данных не должны изменяться. Эти базы данных потенциально могут использоваться двумя разными местоположениями, включая разные кластеры; эти приспособления должны быть перенесены одновременно.

Если мы рассмотрим все эти предположения, необходимо сделать один вывод: чтобы их уважать, мы должны перенести все сайты сразу из-за взаимозависимостей.

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

Устранение зависимостей от баз данных

Одно из самых сложных ограничений — это надежная миграция баз данных вместе с веб-сайтами.

Можем ли мы представить себе 95% надежную миграцию с учетом только баз данных, предоставленных с хостингом (то есть, не считая нетипичных случаев, которые обнаруживаются только путем анализа исходного кода веб-сайтов)?

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

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

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

Это не идеальное решение: добавление сетевого туннеля означает добавление задержки 10 мс. И на некоторых CMS, выполняющих десятки SQL-запросов последовательно, эта задержка быстро заметна. Но, ограничив этот эффект только базами данных без ссылок, мы могли бы упростить это сильное ограничение. Все сайты продолжат работу. Некоторые сайты могут работать медленно, но для наших обычных случаев веб-хостинга последствия минимальны.

Обход зависимости IP-адреса

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

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

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

И наконец, ничто не мешает нам использовать балансировку нагрузки Paris или Gravelines для выполнения этого перенаправления трафика.

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

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

IP-адреса больше не были точкой блокировки. Снижая это ограничение, мы теперь можем переносить клиентов filerz by filerz. Можем ли мы сделать еще лучше?

Перенести filerz как блок

Чтобы добиться большего, нам потребуется декоррелировать клиентов каждого filerz. Как мы могли это сделать?

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

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

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

Теперь у нас есть все элементы для реализации нового сценария миграции!

Давай, сделаем это еще раз.

Наш финальный сценарий

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

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


2 / Построение сетевого соединения между новым и старым центром обработки данных.


3 / Миграция IP-трафика на новый кластер с перенаправлением в Париж для немигрированных сайтов.


4 / Копирование данных без взлома сайтов.


5 / Ночью: отключение сайтов первого filerz, перенос его данных и связанных баз данных.


6 / Ночью: отключение сайтов, миграция второго filerz и связанных баз данных.


7 / Закрытие исходного кластера.


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

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

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

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

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

До скорой встречи для дальнейших приключений!

В прошлом месяце команда OVH и Binder объединилась, чтобы поддержать рост экосистемы BinderHub по всему миру.



Приблизительно 100 000 еженедельных пользователей общедоступного развертывания mybinder.org и 3 000 уникальных репозиториев git, в которых размещены значки Binder, ощущали потребность в дополнительных ресурсах и вычислительном времени.

Сегодня мы рады объявить, что OVH теперь является частью всемирной федерации BinderHubs, поддерживающих mybinder.org. Весь трафик на mybinder.org теперь распределяется между двумя BinderHub: один находится в ведении группы Binder, а другой — в инфраструктуре OVH.

Итак, для тех, кто еще не знает mybinder.org, вот краткое изложение.

Что такое Юпитер?

Jupyter — потрясающий проект с открытым исходным кодом, который позволяет пользователям создавать, визуализировать и редактировать интерактивные записные книжки. Он поддерживает множество популярных языков программирования, таких как Python, R и Scala, а также некоторые стандарты представления, такие как разметка, фрагменты кода, визуализация диаграмм…



Пример локальной записной книжки Jupyter, читающей записную книжку внутри клиента предвидения репозитория OVH GitHub.

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

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

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

Что такое JupyterHub?

JupyterHub — еще более потрясающий проект с открытым исходным кодом, предлагающий многопользовательскую функцию для ноутбуков Jupyter. Благодаря нескольким подключаемым механизмам аутентификации (например, PAM, OAuth), он позволяет создавать записные книжки Jupyter на лету из централизованной инфраструктуры. Затем пользователи могут легко делиться своими записными книжками и правами доступа друг с другом. Это делает JupyterHub идеальным для компаний, учебных аудиторий и исследовательских лабораторий.

Что такое BinderHub?

Наконец, BinderHub — это вишенка на торте: он позволяет пользователям превращать любой репозиторий Git (например, GitHub) в коллекцию интерактивных записных книжек Jupyter одним щелчком мыши.



Binder экземпляр развернутого OVH можно ознакомиться здесь .

• Просто выберите общедоступный репозиторий git (лучше, если он уже содержит записные книжки Jupyter ).
• Скопируйте URL-адрес выбранного репозитория в правильное поле привязки.
• Щелкните кнопку запуска.
• Если связыватель впервые видит предоставленный вами репозиторий, вы увидите журналы компиляции. Ваш репозиторий анализируется и готовится к запуску связанной записной книжки Jupyter .
• После завершения компиляции вы будете автоматически перенаправлены на выделенный экземпляр.
• Затем вы можете начать взаимодействовать и взламывать ноутбук.
• На начальной странице подшивки вы увидите ссылку, по которой можно поделиться своим репозиторием с другими.

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

Инструменты, используемые BinderHub

BinderHub соединяет несколько сервисов вместе, чтобы обеспечить создание и реестр образов Docker на лету. Он использует следующие инструменты:

• Облачный провайдер, такой как OVH.
• Kubernetes для управления ресурсами в облаке
• Helm для настройки и управления Kubernetes.
• Docker для использования контейнеров, которые стандартизируют вычислительные среды.
• Пользовательский интерфейс BinderHub, к которому пользователи могут получить доступ, чтобы указать репозитории Git, которые они хотят создать.
• BinderHub для создания образов Docker с использованием URL-адреса репозитория Git.
• Реестр Docker, в котором размещаются образы контейнеров.
• JupyterHub для развертывания временных контейнеров для пользователей.

Что происходит, когда пользователь щелкает ссылку Binder?

После того, как пользователь щелкает ссылку Binder, происходит следующая цепочка событий:

1. BinderHub разрешает ссылку на репозиторий.
2. BinderHub определяет, существует ли уже образ Docker для репозитория по последней ссылке (хэш, ветка или тег git commit).
3. Если изображение не существует, BinderHub создает модуль сборки, который использует repo2docker для:
   
   • Получите репозиторий, связанный со ссылкой.
   • Создайте образ контейнера Docker, содержащий среду, указанную в файлах конфигурации в репозитории.
   
   
   • Отправьте этот образ в реестр Docker и отправьте информацию реестра в BinderHub для дальнейшего использования.
4. BinderHub отправляет реестр образов Docker в JupyterHub.
5. JupyterHub создает для пользователя модуль Kubernetes, который обслуживает созданный образ Docker для репозитория.
6. JupyterHub отслеживает активность модуля пользователя и уничтожает его после короткого периода бездействия.

Схема архитектуры BinderHub

Как мы это развернули?

На платформе OVH Kubernetes

Одна замечательная особенность проекта Binder заключается в том, что он полностью не зависит от облака, вам просто нужен кластер Kubernetes для развертывания.

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

Для этого мы использовали 2 сервиса в OVH Public Cloud:

• Kubernetes кластер сегодня потребляет 6 узлов 

  C2-15

  экземпляров виртуальных машин (она будет расти в будущем)
• Docker реестра

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

Установка HELM на наш новый кластер

После завершения автоматической установки нашего кластера Kubernetes мы загрузили административный YAML-файл, позволяющий управлять нашим кластером и запускать 

kubectl

на нем команды.

kubectl

это официальный и самый популярный инструмент, используемый для администрирования кластера Kubernetes. Более подробную информацию о том, как его установить, можно найти здесь .
Автоматическое развертывание полного стека Binder уже подготовлено в виде пакета Helm. Helm — это менеджер пакетов для кубернетов, и для работы ему нужны клиентская часть ( 

helm

) и серверная часть ( 

tiller

).
Всю информацию об установке 

helm

и 

tille

можно найти здесь .

Конфигурация нашего развертывания Helm

После 

tiller

установки в нашем кластере все было готово для автоматизации развертывания связующего в нашей инфраструктуре OVH.
Конфигурация 

helm

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

Интеграция в процесс CD / CI binderhub

У них binder team уже был рабочий процесс travis для автоматизации процессов тестирования и развертывания. Все прозрачно, и они раскрывают все свои конфигурации (кроме секретов) в своем проекте GitHub. Нам просто нужно было интегрироваться с их текущим рабочим процессом и разместить нашу конкретную конфигурацию в их репозитории.

Затем мы подождали их следующего запуска рабочего процесса Travis, и он сработал.

С этого момента стек ovh для binder был запущен и доступен всем отовсюду по этому адресу: ovh.mybinder.org/

Что будет дальше?

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

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

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

Специальная благодарность

Мы благодарны командам Binder, Jupyter и QuantStack за их помощь, команде OVH K8s для OVH Managed Kubernetes и OVH Managed Private Registry, а также команде OVH MLS за поддержку. Вы молодцы!

18 июня 2019 года в 19:00 по центральноевропейскому летнему времени были обнаружены 4 уязвимости, влияющие на стек TCP ядра Linux. Эти уязвимости связаны с целочисленным переполнением в ядре Linux, которое может привести к панике ядра, с одной стороны, и с алгоритмической сложностью реализации SACK, приводящей к исчерпанию ресурсов ЦП, с другой стороны. В обоих случаях влияние ограничивается доступностью сервиса.

Кто уязвим?

• Все Linux Oses с ядром 2.6.29 и выше (с марта 2009 г.)
• FreeBSD 12 использует стек RACK TCP. Обратите внимание, что, к счастью, это не стек по умолчанию, вы можете запустить следующую команду, чтобы указать, использует ли ваша система реализацию «RACK» или нет:
  # sysctl net.inet.tcp.cc.algorithm
• Если вы открываете службу TCP в Интернете (веб-службу, ssh, rcp,…), ваша система потенциально может быть затронута, поскольку для успешной атаки требуется только установить TCP-канал.
• Если ваша служба находится за брандмауэром или iptables / pfsense настроен так, чтобы открывать службу только для доверенных IP-адресов, вы в безопасности.

Как исправить?
Есть 3 разных способа, вам нужно выбрать только ОДИН из них.

1. Обновите ядро

Основные дистрибутивы Linux уже выпустили исправление:

• Linux версии 4.4.182 или выше
• Linux версии 4.9.182 или выше
• Linux версии 4.14.127 или выше
• Linux версии 4.19.52 или выше
• Linux версии 5.1.11 или выше.
• Обратите внимание, что ветка Linux версии 3.16 еще не была объявлена ​​исправляемой. (2019-06-18)

Кстати, загляните на веб-сайт вашего дистрибутива (Ubuntu, RedHat, SuSE,…) для получения более подробной информации, поскольку ваш поставщик мог бы перенести патч на собственную версию ядра.

2. Снижение риска брандмауэра

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

3. Отключить SACK (не рекомендуется)

Поскольку основной причиной уязвимости является проблема обработки SACK, вы также можете отключить SACK в своем ядре. Имейте в виду, что SACK — это оптимизация протокола TCP с целью повышения производительности подтверждения пакетов. Отключение этой функции может сильно повлиять на вашу производительность, и мы не рекомендуем это решение.

Является ли эксплойт общедоступным?

Насколько нам известно (18.06.2019), публичных эксплойтов пока нет, но это, вероятно, вопрос часов / дней.

Краткие технические пояснения

CVE-2019-11477

Целочисленное переполнение 16-битного счетчика (tcp_skb_pcount) может произойти в ядре, которое приведет к ошибке BUG_ON (не совсем паника, но оставит вашу систему в нестабильном — потенциально непригодном для использования — состоянии).

Уменьшая значение параметра MSS до небольшого значения, злоумышленник может заставить вашу систему отправлять большое количество пакетов на вредоносный удаленный IP-адрес, находящийся под его контролем. Функция SACK позволит удаленному вредоносному IP подтверждать только несколько пакетов из всех отправленных.

Ваше ядро ​​будет хранить список неподтвержденных пакетов, который увеличивает 16-разрядный счетчик (tcp_skb_pcount), который в какой-то момент переполняется и вызывает ошибку сравнения, приводящую к BUG_ON.

CVE-2019-11478

Используя тот же предыдущий сценарий, злоумышленник может фрагментировать буфер сокета (SKB) ядра Linux, подтвердив только несколько пакетов. Затем структура данных фрагментируется, что снижает производительность и может заставить ядро ​​потреблять больше ЦП.

CVE-2019-11479

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

Идентификационные номера

Эти уязвимости упоминаются в общих уязвимостях и уязвимостях следующим образом:

• CVE-2019-11477: SACK Panic (Linux> = 2.6.29) | CVSS: 8,2
• CVE-2019-11478: медленная работа SACK (Linux <4.15) или чрезмерное использование ресурсов (все версии Linux) | CVSS: 5,3
• CVE-2019-11479: чрезмерное потребление ресурсов из-за низких значений MSS (все версии Linux) | CVSS: 7,5
• CVE-2019-5599: Медлительность SACK (FreeBSD 12 с использованием стека TCP RACK) | Низкая степень серьезности

Внешние ссылки

• https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
• https://access.redhat.com/security/vulnerabilities/tcpsack
• https://aws.amazon.com/fr/security/security-bulletins/AWS-2019-005/
• https://bugzilla.suse.com/show_bug.cgi?id=1137586

В июне 11 — го, исследователи безопасности опубликовал статью под названием « RAMBleed Чтение Биты в памяти без доступа к ним ». В этой статье описывается вектор противодействия модулям динамической оперативной памяти (DRAM), которые уже уязвимы для атак типа Роухаммера.

Системы, использующие модули DRAM, защищенные от атак в стиле Rowhammer, остаются защищенными от RAMBleed.

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



Эта уязвимость упоминается как:

· CVE-2019-0174 cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0174

По словам исследователей, « RAMBleed имеет невысокую скорость чтения памяти — около 3–4 бит в секунду. Это дает достаточно времени для контрмер по очистке памяти, чтобы удалить кратковременные секретные данные из памяти цели ».

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

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

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

В 2018 году мы запустили один из крупнейших проектов в истории OVH: миграцию 3 миллионов веб-сайтов, размещенных в нашем центре обработки данных в Париже. Если вы хотите узнать причины этого титанического проекта, мы рассмотрели их в этом посте.

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

Анатомия веб-хостинга

Для работы веб-сайтам и веб-приложениям обычно нужны две вещи :

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

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

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

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

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

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

Все эти эффекты масштаба позволяют нам предлагать недорогие решения для веб-хостинга (от 1,49 евро в месяц), сохраняя при этом высокий уровень качества. Мы очень коротко объясним, как мы рассчитываем качество обслуживания, но если вы не хотите ждать, посмотрите конференцию, которую наши разработчики провели на FOSDEM 2019.

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

Техническая архитектура наших решений для веб-хостинга

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

Это очень эффективно, но у этого типа архитектуры есть некоторые недостатки :

• В случае поломки восстановление может быть долгим. Если у вас нет репликации системы в реальном времени, что очень дорого, вам нужно восстановить данные из резервной копии, а затем перенести их на новую машину, прежде чем повторно открывать службу для клиентов. Хотя вероятность аппаратного или программного сбоя невелика, это обычная операция в крупных инфраструктурах.
• Чтобы иметь дело с новыми технологиями, было бы предпочтительнее внедрять их на новых серверах только на первом этапе, а затем уделять время постепенному развертыванию их на существующих серверах на будущих этапах.
  Однако на таком быстро развивающемся рынке, как Интернет, становится трудно поддерживать разнородную инфраструктуру. Затем технические группы должны адаптироваться и работать с несколькими различными конфигурациями, что увеличивает риск регресса или поломки. А командам поддержки становится очень сложно запоминать все различные конфигурации и отслеживать текущие изменения.
• Каждый программный блок по своей сути сложен, поэтому для достижения максимальной производительности и качества обслуживания мы создали группы, специализирующиеся на каждой технологии: база данных, среда PHP, системы хранения, сеть… Может быть сложно заставить все эти группы взаимодействовать на одном сервере., и приводят к недопониманию относительно доступности веб-сайтов.
• Трудно выделить клиента, который потребляет больше ресурсов, чем в среднем. Если вам повезет, вы не будете на том же сервере, что и этот клиент, но если да, то производительность вашего веб-сайта может пострадать в результате потребления ресурсов.

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

N- уровневая архитектура

Участки с высоким уровнем нагрузки могут использовать п — уровень архитектуру, чтобы предоставить больше ресурсов для каждого программного кирпича, распределяя их между несколькими серверами. Если мы пойдем дальше с нашим разделением кода / данных, нам понадобится три сервера для запуска веб-сайта:

• Сервер, ответственный за выполнение исходного кода
• Два часто используемых сервера хранения : сервер базы данных и файловый сервер

Файловые серверы: Filerz

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

Ими управляет специальная группа хранения, которая также предоставляет услуги этого типа нескольким другим командам в OVH (веб-хостинг, электронная почта…). Если вас это интересует, они также предлагают NAS-HA, который вы найдете в общедоступном каталоге наших выделенных серверов.

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

Серверы баз данных

Серверы баз данных обычно используются веб-сайтами для динамического размещения данных сайта. Они используют систему управления базами данных (СУБД) (MySQL с нашими решениями), которая структурирует данные и делает их доступными через язык запросов (в нашем случае SQL).

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

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

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

Веб-серверы

Это серверы, которые получают запросы и выполняют исходный код веб-сайта. Они получают свои данные из файлов и баз данных, предоставленных ранее описанными Filerz и серверами баз данных. Основное требование к этим серверам — хорошие ресурсы ЦП, необходимые для выполнения исходного кода.

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

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

Балансировка нагрузки

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

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

Трафик веб-сайта поступает на несколько IP-адресов ( docs.ovh.com/en/hosting/list-addresses-ip-clusters-and-web-hostings/#cluster-025 ), которые мы выделяем для нашей службы веб-хостинга.. Эти IP-адреса управляются нашими балансировщиками нагрузки. Следовательно, они являются отправной точкой нашей инфраструктуры. Кроме того, мы реализовали самые лучшие анти DDoS технологии, чтобы защитить веб — сайтов наших клиентов.

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

Мы также предлагаем решения с гарантированными ресурсами, такие как Performance Hosting, или даже полностью выделенные, например Cloud Web.

Фактически, распределение нагрузки очень сильно привязано к нашим клиентам. Мы изменили систему распространения, добавив блок, предназначенный для OVH, с именем predictor, который выбирает веб-сервер в соответствии с веб-сайтом запроса. В предикторы адаптации к метрикам нашей инфраструктуры, и информация, предоставленная нашей системой.



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

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

Домены сбоя

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

В нашем бизнесе речь идет о разделении инфраструктуры на части и распределении клиентов по разным кластерам. Поэтому мы разделили инфраструктуру Парижа на 12 идентичных кластеров. В каждом кластере мы находим балансировщик нагрузки, веб-серверы и Filerz. Я е один из кластеров идет вниз, « только « 1/12 из клиентов с сайтов, размещенных на этом центре обработки данных затронуты.

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

Итак, в последний раз нам нужно обновить схему нашей инфраструктуры…

Управление инфраструктурой

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

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

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

Поздравляем… теперь вы знаете немного больше о нашей архитектуре! Чтобы узнать, где работает ваш собственный веб-сайт, вы можете найти имена серверов баз данных, Filerz и кластеров, связанных с вашим хостингом, в панели управления OVH.

Технические ограничения для миграции

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

• Все веб-сайты в одном кластере имеют один и тот же IP-адрес.
• Серверы баз данных и кластеры хостинга не коррелируют
• Чтобы перенести веб-сайт, вы должны синхронизировать его миграцию с миграцией всех связанных с ним элементов, то есть балансировщика нагрузки , Filerz и баз данных.
• Исходный код веб-сайта может использовать базу данных, на которую нет ссылок на его веб-хостинге.
• Исходный код может включать ссылки на инфраструктуру (абсолютная ссылка, включая номер файла , имя кластера, имя серверов баз данных ...)

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