Oracle Real Application Clusters в среде Bare Metal Kubernetes Cluster / forpes.ru

Главная
Oracle Real Application Clusters в среде Bare Metal Kubernetes Cluster

Oracle Real Application Clusters в среде Bare Metal Kubernetes Cluster +1

05.04.2023 21:04

itoracle 0 641 Источник

Приветствую всех!

Данная статья рассматривает необходимые и достаточные действия для запуска и настройки RAC 21.3 в кластере kubernetes 1.26. Прецедентов на апрель 2023 г. работы вне Oracle Cloud не найдено, поэтому пришлось провести тысячи экспериментов, отбросить и принять множество гипотез.

На сегодня первая в мире выкатка RAC в kubernetes и без docker.

uname -a

Linux r02 5.4.17-2136.300.7.el8uek.x86_64 #2 SMP Fri Oct 8 16:23:01 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux

OEL 8.5 уже сертифицирована для Oracle RAC, 7.9 можно не устанавливать.

containerd --version

containerd github.com/containerd/containerd v1.6.4 212e8b6fa2f44b9c21b2798135fc6fb7c53efc16

runc --version

runc version 1.0.2

spec: 1.0.2-dev

go: go1.16.7

libseccomp: 2.5.1

Основные задачи настройки выкатки RAC:

Создание и настройка подсетей в кластере kubernetes
Настройка параметров:
1. - ядра рабочего узла kubernetes
2. - ядра контейнера RAC, namespaced и read only.
Выбор и настройка конфигурации используемой RAC оперативной памяти
Настройка общего хранилища RAC в kubernetes.

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

statefulset.yaml

################################################################################
#                                                                              #
#    Author: Serguei Nastassi          itoracle@icloud.com                     #
#    Created 01/03/2023                                                        #            
################################################################################
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: oracle-rac-213
spec:
  serviceName: rdbms
  podManagementPolicy: Parallel
  updateStrategy:
    type: RollingUpdate
  replicas: 1
  selector:
    matchLabels:
      app: oracle-rac-213
  template:
    metadata:
      labels:
        app: oracle-rac-213
      annotations:  
        k8s.v1.cni.cncf.io/networks: '[ 
            {
              "name": "macvlan-conf",
              "ips": ["172.16.1.150/24"]
            },
            {
              "name": "macvlan-priv-conf",
              "ips": ["192.168.17.150/24"]
            }
          ]'
    spec:
      terminationGracePeriodSeconds: 300
      securityContext:
        sysctls:
              - name: kernel.shmall
                value: "2097152"
              - name: kernel.sem
                value: "250 32000 100 128"
              - name: kernel.shmmax
                value: "8589934592"
              - name: kernel.shmmni
                value: "4096"
      containers:
        - name: rdbms
          image: cr.local:32424/container-registry.oracle.com/database/rac:21.3.0.0
          resources:
            requests:
              memory: "16Gi"
            limits:
              memory: "16Gi"
          securityContext:
            privileged: true
            capabilities:
              add: ["SYS_NICE","SYS_RESOURCE","NET_ADMIN","AUDIT_CONTROL","AUDIT_WRITE","SYSLOG","SYS_TIME","SYS_RESOURCE","SYS_RAWIO","SYS_MODULE","SYS_CHROOT","SYS_BOOT","SYS_ADMIN","SETUID","SETGID","NET_BIND_SERVICE","CHOWN"]
            runAsUser: 0
            procMount: "Unmasked"
            allowPrivilegeEscalation: true
          envFrom:
            - configMapRef:
                name: oracle-rdbms-config
          ports:
            - containerPort: 1521
              name: oracle-listener
            - containerPort: 5500
              name: oem-express
          volumeDevices:
            - name: ora-blk0
              devicePath: /dev/asm_disk01
            - name: ora-blk1
              devicePath: /dev/asm_disk02
            - name: ora-blk2
              devicePath: /dev/asm_disk03
            - name: ora-blk3
              devicePath: /dev/asm_disk04
            - name: ora-blk4
              devicePath: /dev/asm_disk05
          volumeMounts:
          - name: oradata
            mountPath: /oradata
          - name: tmpfs
            mountPath: /dev/shm
          - name: hp
            mountPath: /dev/hugepages
          - name: cgroups
            mountPath: /sys/fs/cgroup
#            readOnly: true
          - name: proc
            mountPath: /hostproc
          - name: boot
            mountPath: /boot
            readOnly: true
      volumes:
        - name: oradata
          nfs:
            server: "192.168.1.4"
            path: /home/oracle-rac-213
        - name: ora-blk0
          persistentVolumeClaim:
            claimName: nas-0-oracle-rac-213-0
        - name: ora-blk1
          persistentVolumeClaim:
            claimName: nas-1-oracle-rac-213-0
        - name: ora-blk2
          persistentVolumeClaim:
            claimName: nas-2-oracle-rac-213-0
        - name: ora-blk3
          persistentVolumeClaim:
            claimName: nas-3-oracle-rac-213-0
        - name: ora-blk4
          persistentVolumeClaim:
            claimName: nas-4-oracle-rac-213-0
        - name: tmpfs
          emptyDir:
            medium: Memory
            sizeLimit: 4Gi
        - name: hp
          hostPath:
            path: /dev/hugepages
        - name: cgroups
          hostPath:
            path: /sys/fs/cgroup
            type: Directory
        - name: proc
          hostPath:
            path: /home/hostproc
            type: Directory
        - name: boot
          hostPath:
            path: /boot
            type: Directory
  volumeClaimTemplates:
  - metadata:
      name: nas-0
    spec:
      accessModes:
        - ReadWriteMany
      volumeMode: Block
      resources:
        requests:
          storage: 23Gi
  - metadata:
      name: nas-1
    spec:
      accessModes:
        - ReadWriteMany
      volumeMode: Block
      resources:
        requests:
          storage: 23Gi
  - metadata:
      name: nas-2
    spec:
      accessModes:
        - ReadWriteMany
      volumeMode: Block
      resources:
        requests:
          storage: 23Gi
  - metadata:
      name: nas-3
    spec:
      accessModes:
        - ReadWriteMany
      volumeMode: Block
      resources:
        requests:
          storage: 23Gi
  - metadata:
      name: nas-4
    spec:
      accessModes:
        - ReadWriteMany
      volumeMode: Block
      resources:
        requests:
          storage: 23Gi

Сначала создадим пространство имен:

---
apiVersion: v1
kind: Namespace
metadata:
  name: oracle-rac-213
  labels:
    kubernetes.io/metadata.name: oracle-rac-213
    pod-security.kubernetes.io/enforce: privileged
spec:
  finalizers:
  - kubernetes

Всвязи с отменой podSecurityPolicy с версии 1.23, часть настроек осуществляется в пространстве имен.

Создание сетей и адаптеров

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

По моему мнению любой CNI можно настроить на добавление дополнительных адаптеров контейнеру при запуске.

Для сокращения времени внедрения я использую готовое решение multus, одобренное cncf. При развертывании multus CNI в кластере kubernetes я советую обратить внимание на возможность развертывания только на узлах, где будут работать контейнеры RAC. Даже при отсутствии аннотаций в манифестах никакие контейнеры могут не запуститься по причине некорректных настроек после раскатки multus CNI. Сразу обратите внимание на файл /etc/cni/net.d/00-multus.conf

{ "cniVersion": "0.3.1", "name": "multus-cni-network", "type": "multus", "capabilities": {"portMappings": true}, "kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig", "delegates": [ { "cniVersion": "0.3.1", "name" ……

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

Добавить определения сетей:

---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-conf
spec:
  config: '{
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "macvlan",
          "capabilities": { "ips": true },
          "master": "cni0",
          "mode": "bridge",
          "ipam": {
            "type": "static",
            "routes": [
              {
                "dst": "0.0.0.0/0",
                "gw": "172.16.1.1"
              }
            ]
          }
        }
      ]
    }'

---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-priv-conf
spec:
  config: '{
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "macvlan",
          "capabilities": { "ips": true },
          "master": "enp2s0f1",
          "mtu": 1500,
          "mode": "bridge",
          "ipam": {
            "type": "static"
          }
        }
      ]
    }'

Я специально написал mtu 1500 для приватной сети, зная, что требуются jumbo packets с mtu 9000 и мы получим предупреждение при развертывании grid в журналах. Ничего страшного в этом нет, просто для этой настройки потребуется еще немало работы, которая не входит в текущие планы. Вполне может оказаться, что 20% ускорения при использовании jumbo packets не скажется на общей производительности.

spec. securityContext:sysctls: именно здесь можно объявить для использования в контейнере часть параметров ядра, остальные можно установить на уровне рабочего узла kubernetes.

Для этого используется featureGates на рабочем узле, в файл /var/lib/kubelet/config.yaml добавить строку:

allowedUnsafeSysctls: [kernel.shm*, kernel.sem, net.*]

В файл /etc/kubernetes/manifests/kube-apiserver.yaml добавить

--feature-gates=ProcMountType=true

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

Перезапустить kubelet, swap до этого момента должен быть все еще отключен.

Можно ничего этого не делать, просто все sysctl на уровне хоста добавить в /etc/sysctl.conf и sysctl -p, вопрос перфекционизма. Все требуемое официальной документацией Oracle туда тоже следует непременно добавить.

Для ускорения загрузки образа (20Gi) лучше настроить любой локальный реестр образов.

Потом

podman pull container-registry.oracle.com/database/rac:21.3.0.0

podman push --tls-verify=false <image> docker-service.docker-registry:5000/container-registry.oracle.com/database/rac:21.3.0.0

Для настройки mirror registry в config.toml добавьте имя и порт вашего реестра:

      [plugins."io.containerd.grpc.v1.cri".registry.configs]
        [plugins."io.containerd.grpc.v1.cri".registry.configs."cr.local:32424"]
          [plugins."io.containerd.grpc.v1.cri".registry.configs."cr.local:32424".tls]
            insecure_skip_verify = true

      [plugins."io.containerd.grpc.v1.cri".registry.headers]

      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."cr.local:32424"]
          endpoint = ["https://cr.local:32424"]

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

securityContext:

            privileged: true

Здесь нет никакой ошибки, именно на уровне контейнера и объявляется второй блок securityContext. При сравнении с официальной docker конфигурацией Oracle выясняется существенная разница в работе docker и kubernetes.

Настройка параметров оперативной памяти

Общий объем оперативной памяти на описываемом стенде не очень большой - 20Gb, рекомендованный минимальный объем 16Gb для пода кажется нормальным. Также на узле обязательно работают kube-proxy, flannel, multus, container registry необязательно, экономит время.

Очень важно определиться на каком оборудовании можно и нужно использовать huge pages. По моему личному мнению, основанному на рекомендациях Oracle, официально определенную величину vm.nr_hugepages=16384 не стоит использовать на серверах с объемом физической оперативной памяти менее 64Gb. Попробовать можно, скорее всего база Oracle не стартует. Просто не используйте ее:

sysctl vm.nr_hugepages=0

Сервер БД Oracle сам переключится на использование обычных страниц, которых должно быть достаточно. Тогда следует коррелировать размер SGA и выделенной области /dev/shm. Тут они 3.8Gb и 4Gb соответственно.

Не забудьте отключить transparent huge pages во всех случаях:

sudo echo never > /sys/kernel/mm/transparent_hugepage/enabled

Лучше это сделать на уровне GRUB заранее.

Подготовка к запуску install grid infrastructure

В common_scripts создайте sh файл:

# Init script
sudo mv /etc/ntp.conf /etc/ntp.conf- 
sudo ln -s /oradata/.secrets/common_os_pwdfile.enc /run/secrets/common_os_pwdfile.enc
sudo ln -s /oradata/.secrets/pwd.key /run/secrets/pwd.key
sudo mount --bind /hostproc/net/core /proc/sys/net/core
sudo echo 950000 > /sys/fs/cgroup/cpu/system.slice/cpu.rt_runtime_us
sudo sysctl kernel.sched_rt_runtime_us=-1
sudo sed -i 's/134217728$/8388608/'  /etc/security/limits.conf
sudo yum -y install chrony
sudo systemctl start chronyd

Переименование файла ntp.conf, чтобы избежать ошибки cvu. Непонятно, зачем он оказался в этом образе.

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

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

sudo cp -r /proc/sys/net /home/<…>

В этом командном файле mount --bind успешно подмонтирует этот кусочек в /proc контейнера и мы не увидим ни одной ошибки cvu ни журналов контейнера.

kernel.sched_rt_runtime_us=-1 на этой «-1» тут, честно говоря все и держится :) Данный параметр позволяет root процессам контейнера запускать процессы с приоритетом RT. ASM с версии 19.3 по другому работать не будет. 18.3 еще работает.

Система должна быть загружена со значением DefaultCPUAccounting=no в /etc/systemd/system.conf Иначе не заработает realtime в контейнере.

/etc/security/limits.conf содержит нереальное значение memlock 128Gb, база запускаться не будет, поэтому для системы 20Gb на все выделим по 8Gb на ASM и 8Gb на Oracle.

Chronyd пришел на смену ntp и он тут стартует.

Данный файл следует выполнить в первые 60 секунд работы контейнера, для этого там время и выделено.

kubectl -n oracle-rac-213 exec -it oracle-rac-213-0 -- bash /oradata/scripts/ini.sh

Разделяемое Хранилище

Разверните 1 или более nfs серверов для раздачи каталога с файлами хранилища. При наличии специализированного NAS оборудования тут можно много пропустить.

Подготовьте 2 или более файла на nfs серверах согласно документации Oracle.

Я использую немного другое, но очень быстрое решение:

cd /home/oracle-rac-213/

sudo fallocate -z -o 0 -l 23G asm_disk01.img

sudo fallocate -z -o 0 -l 23G asm_disk02.img

sudo fallocate -z -o 0 -l 23G asm_disk03.img

sudo fallocate -z -o 0 -l 23G asm_disk04.img

sudo fallocate -z -o 0 -l 23G asm_disk05.img

Наличие нулевых блоков хранится в метаданных файловой системы.

На рабочем узле kubernetes смонтируйте шару:

mkdir -p /mnt/ora

mount -t nfs 192.168.1.4:/home/oracle-rac-213 /mnt/ora

Смонтируйте каждый файл как устройство:

losetup -f /mnt/ora/asm_disk01.img

… И т.д.
Теперь можно объявить все persistent volumes:

---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: nas-0
spec:
  volumeMode: Block
  capacity:
    storage: 23Gi
  local:
    path: /dev/loop0
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
            - r02

Все объявить надо.

Persistent volume claims у нас объявлены в statefulset manifest.

Настройки

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: oracle-rdbms-config
  labels:
    app: oracle-rac-213
data:
#  IGNORE_CVU_CHECKS: "true"
#
  CLUSTER_NAME: "ora-213"
#  DHCP_CONF: "TRUE"
  NODE_VIP: "172.16.1.160"
  VIP_HOSTNAME: "oracle-rac-213-0-v"
  PUBLIC_IP: "172.16.1.150"
  PUBLIC_HOSTNAME: "oracle-rac-213-0"
  SCAN_NAME: "ora-scan"
#  SCAN_IP: "172.16.1.70"
  PRIV_IP: "192.168.17.150"
  PRIV_HOSTNAME: "oracle-rac-213-0-p"
#
#  CMAN_IP: "172.16.1.15"
#  CMAN_HOSTNAME: "cman-1"
  #
  COMMON_OS_PWD_FILE: "common_os_pwdfile.enc"
  PWD_KEY: "pwd.key"
  #
  DOMAIN: "oracle-rac-213.svc.cluster.local"
#  DNS_SEARCH: "10.96.0.10"
#  DNS_SERVERS: "192.168.1.1"  #"10.96.0.10"
#  DEFAULT_GATEWAY: "172.16.1.1"       # within container
  ASM_DEVICE_LIST: "/dev/asm_disk01,/dev/asm_disk02,/dev/asm_disk03,/dev/asm_disk04,/dev/asm_disk05"
  ASM_DISCOVERY_DIR: "/dev"
#  GRID_RESPONSE_FILE: "grid_sample.rsp"
#  DBCA_RESPONSE_FILE: "dbca_sample.rsp"
  OP_TYPE: "INSTALL"

Не указываю явно DNS сервер, нормальный режим работы Oracle, он будет ориентироваться на resolv.conf, далее cluster dns. Главное в этой цепочке указать соответствие имен хостов из этого списка и их адресов, для SCAN указать все 3 адреса 172.16.1.70 - 172.16.1.72. Я использовал dns сервер из внешнего к кластеру kubernetes сетевого домена, поэтому пришлось указывать все 2 раза с доменом и без. Имя домена в контейнере образуется по правилам kubernetes: oracle-rac-213.svc.cluster.local

Включение swap

sudo fallocate -l 32G /swap.img

sudo chmod 600 /swap.img

sudo mkswap /swap.img

sudo swapon /swap.img

Запуск и мониторинг

Примените все манифесты, начиная с создания пространства имен и заканчивая statefulset.

Я использую Argocd:

Сервисы для доступа к БД и OEM можно получить в моем репозитории https://github.com/itoracl/oracle-rac-213, как и все вышеприведенные манифесты.

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

**Примерно через час видим полный good luck screen**

Выполним внутри контейнера:

[grid@oracle-rac-213-0 ~] $ crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

[grid@oracle-rac-213-0 ~] $ crsctl status resource -w "TYPE co ’ora’" -t

--------------------------------------------------------------------------------

Name Target State Server State details

--------------------------------------------------------------------------------

Local Resources

--------------------------------------------------------------------------------

ora.LISTENER.lsnr

ONLINE ONLINE oracle-rac-213-0 STABLE

ora.chad

ONLINE ONLINE oracle-rac-213-0 STABLE

ora.net1.network

ONLINE ONLINE oracle-rac-213-0 STABLE

ora.ons

ONLINE ONLINE oracle-rac-213-0 STABLE

--------------------------------------------------------------------------------

Cluster Resources

--------------------------------------------------------------------------------

ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)