文章目錄

前言
實作環境
實作 Redis Sentinel 高可用性容器化
          建立 Docker Swarm 運作環境
          客製化 Redis Master / Slave 容器映像檔
          客製化 Redis Sentinel 容器映像檔
          客製化 Redis-Stat 容器映像檔
          執行 Docker Stack Deploy 佈署作業
          驗證和容錯移轉測試
          摧毀環境
參考資源





前言

簡單來說,希望透過「容器化」(Containerzation)的方式,將 Redis Sentinel 高可用性機制打包封裝後,以便在 Docker 容器管理環境中便能非常快速的建立 Redis Sentinel 高可用性機制。

本文將會在 Docker Swarm (3 Nodes) 的運作環境中實作,並且採用最新 Docker Compose v3 以及 docker stack deploy 指令進行佈署作業 (從 Docker 1.13 版本開始發佈新的 Docker Compose 並且支援 Swarm Mode,以便達成 Multi-Container on Multi-Host 的目標)。下列為 Docker Compose v2 / v3 的簡易比較表格:


佈署服務
查詢服務
擴展服務
關閉服務
支援多台容器主機
No
Yes

倘若你將編寫好的 YAML 檔案,透過 Docker Compose v2 佈署到 Docker Swarm 運作環境時會發生什麼事? 此時,系統便會提醒你目前的 Docker Engine 已經處於 Swarm Mode,如果希望佈署到「多台容器主機」上的話,請改為採用 docker stack deploy 指令來進行佈署。

圖、必須使用 docker stack deploy 指令才能佈署容器至多台主機





實作環境

快速建置:
1. 建構好 Docker Swarm 運作環境。
2. 下載本文相關檔案 git clone https://github.com/Weithenn/redis-sentinel
3. 執行 build.sh 即可建構好 Redis Sentinel 高可用性機制 (如果順利的話 😁)。





    實作 Redis Sentinel 高可用性容器化

    建立 Docker Swarm 運作環境

    簡單來說,當企業及組織建立的容器數量越來越多需要管理平台或建立容器叢集架構時,就可以透過建置 Docker Swarm 運作環境來達成。從 Docker 1.12.0 版本之後,便直接原生內建 Docker Swarm Mode 並且容器主機,已經可以「同時」擔任 Manager 及 Workers 的角色。

    下列為 Swarm Cluster Protocol / Ports 資訊:
    • 2377 (TCP) - Swarm Cluster management。
    • 7946 (TCP and UDP) - Nodes communication。
    • 4789 (UDP) - Overlay network traffic,IP Protocol 50 (ESP) - Overlay network with encryption (--opt encrypted)。

    圖、Docker Swarm 運作架構示意圖

    圖、Docker Swarm 工作任務示意圖


    同時,為了維持 Docker Swarm Mode 的高可用性,根據 Docker 官方建議應該要建立「奇數」的 Manager Node 才對,舉例來說:
    • 3 Manager Node Swarm Cluster 可允許 1 台故障 (N-1/2)
    • 5 Manager Node Swarm Cluster 可允許 2 台故障 (N-1/2)
    • Docker 官方建議每個 Swarm Cluster 最多 7 台 Manager Node (更多的 Manager Node 很有可能會造成反效果)。
    • 當 Manager Node 死光,Worker Node 上的 Container 仍能繼續運作,然而將無法執行 Add/Update/Remove Node 等維護動作 (後續要執行復原的動作)。

    圖、Docker Swarm 高可用性規劃

    在本文實作環境中,採用 3 台 CentOS 7.4 主機擔任 Container Host (Swarm Node),這 3 台 CentOS 主機的主機名稱、IP 位址、Swarm Role 資訊如下:
    • swarm01.weithenn.org, 10.10.75.71, Manager / Worker
    • swarm02.weithenn.org, 10.10.75.72, Manager / Worker
    • swarm03.weithenn.org, 10.10.75.73, Manager / Worker

    有關 CentOS 7.4 基礎設定和 CentOS 安裝 Docker 環境的部分請參考站內文章,在本文實作環境中 3 台 CentOS 主機,都「同時」擔任 Docker Swarm Manager / Worker 的角色,以便互相調度及運作容器。

    圖、Docker Swarm Cluster (3 Nodes)





    客製化 Redis Master / Slave 容器映像檔

    Docker Swarm 容器叢集環境建構完成後,接著就可以準備客製化 Redis Master / Slave 容器映像檔 (因為要組態設定符合需求的設定檔)。在本文實作環境中,我們將會採用 redis:4.0.6-alpine 容器映像檔進行客製化作業。

    Redis Master - Dockerfile (GitHub - Weithenn/redis-sentinel/redis-master/Dockerfile),主要客製化的項目如下:

    FROM redis:4.0.6-alpine
    MAINTAINER Weithenn Wang <weithenn@weithenn.org>
    # Install tzdata for Timezone
    RUN apk add --no-cache tzdata && \
        \
    # Download Redis configuration file example
        cd /tmp && \
        wget http://download.redis.io/redis-stable/redis.conf && \
        mkdir -p /etc/redis && \
        cp redis.conf /etc/redis/ && \
        \
    # This is Redis [Master] confgiruation
    # bind 0.0.0.0, Disable RDB file and AOF log, tuning TCP backlog
        sed -i 's,bind 127.0.0.1,bind 0.0.0.0,g' /etc/redis/redis.conf && \
        sed -i 's/^\(save .*\)$/# \1/' /etc/redis/redis.conf && \
        sed -i 's,#   save "",save "",g' /etc/redis/redis.conf && \
        sed -i 's,stop-writes-on-bgsave-error yes,stop-writes-on-bgsave-error no,g' /etc/redis/redis.conf && \
        sed -i 's,hz 10,hz 50,g' /etc/redis/redis.conf && \
        sed -i 's,tcp-backlog 511,tcp-backlog 32768,g' /etc/redis/redis.conf && \
        \
    # Tuning TCP backlog, No memory overcommit handling, Disable THP(Transparent Huge Pages)
    # Please reference Redis Administration (https://redis.io/topics/admin)
        touch /etc/redis/run.sh && \
        echo "echo 32768 > /wproc/sys/net/core/somaxconn" >> /etc/redis/run.sh && \
        echo "echo 1 > /wproc/sys/vm/overcommit_memory" >> /etc/redis/run.sh && \
        echo "echo never > /wsys/kernel/mm/transparent_hugepage/enabled" >> /etc/redis/run.sh && \
        echo "echo never > /wsys/kernel/mm/transparent_hugepage/defrag" >> /etc/redis/run.sh && \
        echo "redis-server /etc/redis/redis.conf" >> /etc/redis/run.sh && \
        chmod 755 /etc/redis/run.sh && \
        chown -R redis:redis /etc/redis
    ENV TZ=Asia/Taipei
    EXPOSE 6379/tcp
    CMD ["/etc/redis/run.sh"]



    Redis Slave - Dockerfile (GitHub - Weithenn/redis-sentinel/redis-slave/Dockerfile),客製化的部分基本上跟 Redis Master 一模一樣,唯一的差別在於 redis.conf 組態設定檔當中,加上 1 行「slaveof redis_master 6379」內容,也就是指定誰是 Redis Master 主機,其中的 redis_master 為本文實作環境中自訂的 Swarm Native Service Discovery 名稱。

    FROM redis:4.0.6-alpine
    MAINTAINER Weithenn Wang <weithenn@weithenn.org>
    # Install tzdata for Timezone
    RUN apk add --no-cache tzdata && \
        \
    # Download Redis configuration file example
        cd /tmp && \
        wget http://download.redis.io/redis-stable/redis.conf && \
        mkdir -p /etc/redis && \
        cp redis.conf /etc/redis/ && \
        \
    # This is Redis [Slave] confgiruation
    # bind 0.0.0.0, Disable RDB file and AOF log, tuning TCP backlog
        sed -i 's,bind 127.0.0.1,bind 0.0.0.0,g' /etc/redis/redis.conf && \
        sed -i 's,# slaveof <masterip> <masterport>,slaveof redis_master 6379,g' /etc/redis/redis.conf && \
        sed -i 's/^\(save .*\)$/# \1/' /etc/redis/redis.conf && \
        sed -i 's,#   save "",save "",g' /etc/redis/redis.conf && \
        sed -i 's,stop-writes-on-bgsave-error yes,stop-writes-on-bgsave-error no,g' /etc/redis/redis.conf && \
        sed -i 's,hz 10,hz 50,g' /etc/redis/redis.conf && \
        sed -i 's,tcp-backlog 511,tcp-backlog 32768,g' /etc/redis/redis.conf && \
        \
    # Tuning TCP backlog, No memory overcommit handling, Disable THP(Transparent Huge Pages)
    # Please reference Redis Administration (https://redis.io/topics/admin)
        touch /etc/redis/run.sh && \
        echo "echo 32768 > /wproc/sys/net/core/somaxconn" >> /etc/redis/run.sh && \
        echo "echo 1 > /wproc/sys/vm/overcommit_memory" >> /etc/redis/run.sh && \
        echo "echo never > /wsys/kernel/mm/transparent_hugepage/enabled" >> /etc/redis/run.sh && \
        echo "echo never > /wsys/kernel/mm/transparent_hugepage/defrag" >> /etc/redis/run.sh && \
        echo "redis-server /etc/redis/redis.conf" >> /etc/redis/run.sh && \
        chmod 755 /etc/redis/run.sh && \
        chown -R redis:redis /etc/redis
    ENV TZ=Asia/Taipei
    EXPOSE 6379/tcp
    CMD ["/etc/redis/run.sh"]



    經過上述客製化程序後,建立的容器映像檔如下 (已經綁定 Automated build 機制),Tags 版本則是直接跟採用的 Redis-Apline 版本對齊
    圖、倘若未處理核心參數啟動 Redis 將會發生相關警告訊息



    客製化 Redis Sentinel 容器映像檔

    簡單來說,Redis Sentinel 機制為「監控 Redis (Master) Instance 當無回應時,切換至 Redis (Slave) Instance 接手」,透過 Redis Sentinel 可以為 Redis 運作架構提供下列功能:
    • Monitoring: 持續檢查 Redis Master / Slave 之間是否正常運作。
    • Notification: 可以透過 API 通知管理人員被監控的 Redis Instance 是否發生問題。
    • Automatic failover: 當 Sentinel 判定 Redis Master 故障時,將存活的 Redis Slave 執行 Promoted to Master 的動作。
    • Configuration provider: 組態設定其它 Redis Slave (變成指向至新的 Master),讓 Application 能夠連接到新的 Redis Master。

    Redis Sentinel 為 Distributed System 的設計架構 (Multiple Sentinel processes cooperating together),這樣設計架構主要是為了「避免誤判」:
    • Redis 2.8 版本開始內建 Sentinel v2,並採用更強大更簡單的「預測演算法」(Predict Algorithms)。
    • 建議「至少 3 台」Sentinel Instances 並確認開啟 TCP Port 26379 (否則不會自動切換)。
    • 採用「非同步複寫」(Asynchronous Replication),所以 Failover 事件觸發時並無法保證所有資料都寫入完畢。

    圖、Redis Sentinel 建議採用的基礎架構 (Redis Master *1、Redis Slave *2、Redis Sentinel *3)

    Redis Sentinel - Dockerfile (GitHub - Weithenn/redis-sentinel/redis-sentinel/Dockerfile),主要客製化的項目如下:
    • 時區: Asia / Taipei。
    • sentinel.conf 組態設定檔:  關閉 Protected Mode、指定 Redis Master 主機、Quorum 數量設定為 2、當 Redis Master 60 秒沒回應判定故障、當 Redis Failover 機制作用後只有 1 台 Redis Slave 能與 Redis Master 同步資料。
    • run.sh: 由於 Docker Compose v3 中 sysctls 參數「尚未支援」docker stack deploy 佈署機制,所以透過這樣的方式來調整 Redis 運作環境所需要的系統核心參數,否則啟動 Redis Sentinel 機制時將會出現 TCP Backlog 的警告訊息。

    FROM redis:4.0.6-alpine
    MAINTAINER Weithenn Wang <weithenn@weithenn.org>
    # Install tzdata for Timezone
    RUN apk add --no-cache tzdata && \
        \
    # Download Redis Sentinel configuration file example
        cd /tmp && \
        wget http://download.redis.io/redis-stable/sentinel.conf && \
        mkdir -p /etc/redis && \
        cp sentinel.conf /etc/redis/ && \
        sed -i 's,# protected-mode no,protected-mode no,g' /etc/redis/sentinel.conf && \
        sed -i 's,sentinel monitor mymaster 127.0.0.1 6379 2,sentinel monitor redis-ha redis_master 6379 2,g' /etc/redis/sentinel.conf && \
        sed -i 's,sentinel down-after-milliseconds mymaster 30000,sentinel down-after-milliseconds redis-ha 5000,g' /etc/redis/sentinel.conf && \
        sed -i 's,sentinel parallel-syncs mymaster 1,sentinel parallel-syncs redis-ha 1,g' /etc/redis/sentinel.conf && \
        sed -i 's,sentinel failover-timeout mymaster 180000,sentinel failover-timeout redis-ha 60000,g' /etc/redis/sentinel.conf && \
        \
    # Tuning TCP backlog
    # Please reference Redis Administration (https://redis.io/topics/admin)
        touch /etc/redis/run.sh && \
        echo "echo 32768 > /wproc/sys/net/core/somaxconn" >> /etc/redis/run.sh && \
        echo "redis-sentinel /etc/redis/sentinel.conf" >> /etc/redis/run.sh && \
        chmod 755 /etc/redis/run.sh && \
        chown -R redis:redis /etc/redis
    ENV TZ=Asia/Taipei
    EXPOSE 26379/tcp
    CMD ["/etc/redis/run.sh"]


    經過上述客製化程序後,建立的容器映像檔如下 (已經綁定 Automated build 機制),Tags 版本則是直接跟採用的 Redis-Apline 版本對齊:



    客製化 Redis-Stat 容器映像檔

    Redis-Stat 是個採用 Ruby 所撰寫的 Redis Monitor Tool。目前,在 Docker Hub 當中並沒有官方打包的容器映像檔,所以只好自行建立 Dockerfile 並打包成容器映像檔。

    Redis-Stat - Dockerfile (GitHub - Weithenn/redis-sentinel/redis-stat/Dockerfile),主要採用 ruby:2.4 容器映像檔 (底層作業系統為 Debian OS),然後組態設定時區為 Asia / Taipei 並安裝 redis-stat

    FROM ruby:2.4
    MAINTAINER Weithenn Wang <weithenn@weithenn.org>
    # Install redis-stat and setting Timezone
    RUN gem install redis-stat && \
        echo Asia/Taipei > /etc/timezone && \
        dpkg-reconfigure -f noninteractive tzdata
    EXPOSE 63790/tcp
    CMD ["redis-stat"]


    經過上述客製化程序後,建立的容器映像檔如下 (已經綁定 Automated build 機制),Tags 版本則是直接跟採用的 Ruby 2.4 版本對齊:



    執行 Docker Stack Deploy 佈署作業

    前置作業都完成後,終於可以透過 docker stack deploy 進行佈署作業了。我們先將所有操作進行分解,了解整個運作流程後便可以使用 Shell Script (build.sh) 將整個流程串起來一氣呵成了。

    Docker Swarm 虛擬網路環境
    在目前還未進行 docker stack deploy 佈署作業之前,可以看到目前虛擬網路只有基礎的「bridge、host、none」,以及建構 Docker Swarm 叢集環境所新增的「docker_gwbridge、ingress」

    圖、目前的 Docker Swarm 虛擬網路環境


    佈署 Redis Master 角色容器 (GitHub - Weithenn/redis-sentinel/01-redis-master.yml)
    首先,我們透過「docker stack deploy -c 01-redis-master.yml redis」指令,來建立 Redis 環境的虛擬網路及佈署擔任 Redis Master 角色的容器。

    version: '3.4'
    services:
      master:
        image: weithenn/redis-master:latest
        ports:
          - "6379:6379"
        volumes:
          - /proc:/wproc
          - /sys:/wsys
        networks:
          - vnet
        deploy:
          replicas: 1
          update_config:
            delay: 60s
    networks:
      vnet:


    可以看到,順利建立「redis_vnet」虛擬網路環境,以及佈署 Redis Master 角色容器並且也 Listen Port 6379

    圖、順利建立 redis_vnet 虛擬網路及佈署 Redis Master 角色容器

    並且,使用「docker service logs redis_master」查看 Redis Master 角色容器日誌訊息,可以看到順利啟動 Redis 並且沒有警告訊息。

    圖、順利啟動 Redis 服務並且沒有任何警告訊息


    佈署 Redis Slave 角色容器 (GitHub - Weithenn/redis-sentinel/02-redis-slave.yml)
    接著,我們透過「docker stack deploy -c 02-redis-slave.yml redis」指令,使用剛才已經建立的 redis_vnet 虛擬網路環境,並且佈署擔任 Redis Slave 角色的容器。

    version: '3.4'
    services:
      slave:
        image: weithenn/redis-slave:latest
        ports:
          - "6380:6379"
        volumes:
          - /proc:/wproc
          - /sys:/wsys
        networks:
          - vnet
        deploy:
          replicas: 2
          update_config:
            delay: 60s
    networks:
      vnet:


    可以看到,順利佈署 2 台 Redis Slave 角色容器並且也 Listen Port 6379 (6380 -> 6379)

    圖、順利佈署 2 台 Redis Slave 角色容器

    使用「docker service logs redis_slave」查看 Redis Slave 角色容器日誌訊息,可以看到順利啟動 Redis 並且成功找到 Redis Master 角色並進行同步作業 (主要就是依靠 Swarm Native Service Discovery  機制)。

    圖、順利佈署 Redis Slave 並與 Redis Master 進行同步作業

    使用「docker service logs redis_master」查看 Redis Master 角色容器日誌訊息,可以看到發現 2 台 Redis Slave 要求進行同步作業。

    圖、Redis Master 發現 2 台 Redis Slave 要求進行同步作業


    佈署 Redis Sentinel 角色容器 (GitHub - Weithenn/redis-sentinel/03-redis-sentinel.yml)
    接著,我們透過「docker stack deploy -c 03-redis-sentinel.yml redis」指令,使用剛才已經建立的 redis_vnet 虛擬網路環境,並且佈署擔任 Redis Sentinel 角色的容器。

    version: '3.4'
    services:
      sentinel:
        image: weithenn/redis-sentinel:latest
        ports:
          - "26379:26379"
        volumes:
          - /proc:/wproc
        networks:
          - vnet
        deploy:
          replicas: 3
          update_config:
            delay: 60s
    networks:
      vnet:


    可以看到,順利佈署 3 台 Redis Sentinel 角色容器並且也 Listen Port 26379

    圖、順利佈署 3 台 Redis Sentinel 角色容器

    使用「docker service logs redis_sentinel」查看 Redis Sentinel 角色容器日誌訊息,可以看到順利啟動 Redis Sentinel 機制,並且成功找到 Redis Master / Slave 角色和運作情況 (同樣依靠 Swarm Native Service Discovery  機制)。

    圖、順利佈署 Redis Sentinel 並成功找到 Redis Master / Slave 角色


    佈署 Redis-Stat 角色容器 (GitHub - Weithenn/redis-sentinel/04-redis-stat.yml)
    接著,我們透過「docker stack deploy -c 04-redis-stat.yml redis」指令,使用剛才已經建立的 redis_vnet 虛擬網路環境,並且佈署擔任 Redis-Stat 角色的容器。

    version: '3.4'
    services:
      stat:
        image: weithenn/redis-stat:latest
        command: redis-stat --server redis_master
        ports:
          - "80:63790"
        networks:
          - vnet
        deploy:
          replicas: 1
          update_config:
            delay: 60s
    networks:
      vnet:


    可以看到,順利佈署 1 台 Redis-Stat 角色容器並且也 Listen Port 63790 (80 -> 63790)

    圖、順利佈署 Redis-Stat 角色容器

    使用「docker service logs redis_stat」查看 Redis-Stat 角色容器日誌訊息,可以看到順利啟動 Redis-Stat 監控機制,並且開始收集 Redis Master 運作情況 (同樣依靠 Swarm Native Service Discovery  機制)。

    圖、順利佈署 Redis-Stat 並開始收集 Redis Master 運作情況

    圖、順利佈署 Redis-Stat 並開始收集 Redis Master 運作情況


    佈署 Poitainer 角色容器 (GitHub - Weithenn/redis-sentinel/05-portainer.yml)
    接著,我們透過「docker stack deploy -c 05-portainer.yml redis」指令,使用剛才已經建立的 redis_vnet 虛擬網路環境,並且佈署便於操作及管理容器的 GUI 圖形管理工具。因為,在本文實作環境中,3 台主機都是同時擔任 Docker Swarm Manager / Worker 的角色,所以在佈署 Portainer 容器時無須再特意指定運作在 Manager Node 的部分。詳細資訊,請參考官網文件 Portainer documentation — Portainer 1.15.3 documentation

    version: '3.4'
    services:
      portainer:
        image: portainer/portainer
        command: -H unix:///var/run/docker.sock
        ports:
          - "9000:9000"
        networks:
          - vnet
        volumes:
          - "/var/run/docker.sock:/var/run/docker.sock"
          - "/tmp:/data"
    networks:
      vnet:


    可以看到,順利佈署 1 台 Portainer 容器並且也 Listen Port 9000

    圖、順利佈署 Portainer 管理工具容器

    使用「docker service logs redis_portainer」查看 Portainer 角色容器日誌訊息,可以看到順利啟動 Portainer 管理工具服務。

    圖、順利啟動 Portainer 管理工具服務

    現在,我們可以登入 Portainer 管理工具的操作介面。💪

    圖、Portainer 管理介面

    圖、透過 Portainer 查看 Docker Swarm 環境

    了解整個建置的流程後,其實我們可以用個簡單的 Shell Script 串起所有建構流程。

    #!/bin/sh
    #$Id: build.sh v0.1, 2017/12/08 Weithenn Wang (weithenn@weithenn.org) Exp $
    #Buildup Redis Sentinel provides HA(High Availability) for Redis
    echo ------------------------------------------------
    echo Deploy Redis [Master *1] Node
    echo ------------------------------------------------
    docker stack deploy -c 01-redis-master.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------
    echo Deploy Redis [Slave *2] Nodes
    echo ------------------------------------------------
    docker stack deploy -c 02-redis-slave.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------
    echo Deploy Redis [Sentinel *3] Nodes
    echo ------------------------------------------------
    docker stack deploy -c 03-redis-sentinel.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------
    echo Deploy Redis-Stat Monitor Tool
    echo ------------------------------------------------
    docker stack deploy -c 04-redis-stat.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------
    echo Deploy Portainer GUI Tool
    echo ------------------------------------------------
    docker stack deploy -c 05-portainer.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------------
    echo Verify Docker Swarm Service for Redis Sentinel HA
    echo ------------------------------------------------------
    docker service ls
    echo
    echo
    docker stack ps redis
    echo
    echo
    echo ------------------------------------------------------
    echo Verify Redis Master/Slave/Sentinel Status
    echo ------------------------------------------------------
    echo Redis Master IP address is:
    redis-cli -p 26379 SENTINEL get-master-addr-by-name redis-ha
    echo
    echo
    redis-cli -p 26379 info Sentinel



    驗證和容錯移轉測試

    Redis Master / Slave 及 Redis Sentinel 高可用性機制成形後,我們先再次驗證是否能夠順利看到 Redis 高可用性相關資訊。請使用「redis-cli -p 26379 SENTINEL get-master-addr-by-name redis-ha」指令,查詢 Redis Master 的 IP 位址 (其中 redis-ha 是在 sentinel.conf 組態設定檔,自行指定的 Redis 高可用性服務名稱),以及「redis-cli -p 26379 info Sentinel」指令查看 Redis Sentinel 高可用性機制資訊 。

    圖、查詢 Redis Sentinel 高可用性機制資訊

    在本文實作環境中,透過「docker stack ps redis」指令可以看到 Redis Master 角色容器,目前運作在 swarm02.weithenn.org 的容器主機上,我們直接去 swarm02 主機上停用 Redis Master 角色容器,然後觀察 Redis Sentinel 日誌資訊即可得知 Redis Master / Slave Auto-Failover 的情況。

    圖、Sentinel 發現 Redis Master (10.0.0.5) 故障由 Redis Slave (10.0.0.8) 接手

    圖、這次的切換是透過 3 台 Sentinel 中的 2 台同意的結果

    圖、原 Redis Slave (10.0.0.8) 順利接手成為 Redis Master

    圖、看到剛才測試容錯移轉時故障的 Redis Master 容器



    摧毀環境

    練習完畢💨,要摧毀環境也很容易。只要執行「docker stack rm redis」便可以刪除剛才所有建立的環境 (redis_vnet 虛擬網路、Redis Master、Redis Slave、Redis Sentinel、Redis-Stat、Portainer)。

    圖、破壞總是比建設容易💩





    參考資源


    網管人雜誌

    本文刊載於 網管人雜誌第 142 期 - 2017 年 11 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。





    文章目錄

    前言
    實戰 Horizon 7 基礎架構組態設定
              建構 vSphere 虛擬化平台
              建立 Windows AD 網域環境
              建構 Connection 伺服器角色
              建構 SQL Server 資料庫
              建構 Composer 伺服器角色
              新增 Horizon 7 軟體授權
              新增 vCenter / Composer 伺服器角色
              組態設定 Event 資料庫
    結語





    前言

    事實上,VMware VDI 虛擬桌面解決方案,從 2008 年開始發行 VMware View Manager 3 產品,經過多年的演變已經是非常成熟且豐富的 VDI 虛擬桌面解決方案,最新版本為 2017 年 6 月 20 日所發佈的 VMware Horizon 7.2,除了原有特色功能不斷增強並新增其它特色功能,例如,Horizon Help Desk Tool、Instant Clones、True SSO、Smart Policies、Blast Extreme……等之外,對於開始源始碼的 Linux 作業系統也不斷提升支援度,例如,Horizon Agent for Linux

    同時,隨著 VMware vSAN(Virtual SAN)軟體定義儲存技術不斷發展,新版的 VMware Horizon 也能與最新版本的 Virtual SAN 6.6 一起協同運作,擔任 VDI 虛擬桌面儲存資源的角色,並且整合 vSAN 加密機制保護企業及組織的機敏資訊。

    那麼,讓我們來看看最新推出的 VMware Horizon 7.2 版本中,有哪些重要或新增的亮眼特色功能:
    • Horizon Help Desk Tool: VMware Horizon 的管理人員,可以透過 Horizon Help Desk Tool 取得 Horizon 7 使用者工作階段的運作狀態,以便幫助使用者進行故障排除和維運作業。
    • 增強的身分驗證機制: 透過「遞迴解除鎖定」(Recusive Unlock)特色功能,可以在使用者的 VDI 虛擬桌面主機在解除鎖定後,將所有遠端的連線工作階段也一併解除鎖定。
    • Workspace ONE 存取原則: VMware Horizon 的管理人員,只要在 Horizon Administrator 管理介面中組態設定 Workspace ONE 存取原則,便可以讓使用者透過 Workspace ONE 登入後,存取已經發佈的桌面平台和應用程式。
    • Cloud Pod 運作架構: VMware Horizon 的管理人員,可以在 Horizon Administrator 管理介面中組態設定受限制的全域權利。同時,整個 Cloud Pod 的工作階段總數上限增加至 120,000。
    • True SSO: 透過為連線伺服器組態設定 LDAP URL 過濾機制,以便識別沒有 AD UPN 的網域使用者帳號。
    • 增強的連線伺服器: 單台連線伺服器執行個體的同時連線數量上限增加至 4,000,包括 Direct Connections、PcoIP 安全閘道連線、Blast 安全閘道連線。同時,單台連線伺服器可為 vCenter Server 提供 4,000 個完整複製、即時複製、連結複製等工作任務。
    • vSAN: 可以在 Horizon 7 佈署環境中順利啟用 vSAN 加密功能,以便保護企業及組織的機敏資訊。
    • 已發佈的應用程式和集區: VMware Horizon 的管理人員,可以透過智慧原則機制來管控已發佈應用程式的行為,並且將標記新增至應用程式集區當中,以便應用程式在 Horizon Client 當中更快速開啟。
    • Horizon Agent for Linux: 建立的 Linux 虛擬桌面,可以支援 CDR 用戶端磁碟機重新導向、USB 裝置重新導向、HTML Access 音訊輸出等特色功能。同時,支援主流 RHEL 6 / 7 及 CentOS 6 / 7 版本。

    圖 1、Horizon 7 運作架構示意圖





    實戰 Horizon 7 基礎架構組態設定

    了解最新 Horizon 7 虛擬桌面運作架構及特色功能後,在開始進行 Horizon 7 基礎架構的組態設定作業之前,先了解在 VMware Horizon 的運作架構中,需要建置的角色共有 ESXi 虛擬化平台、vCenter Server、Windows AD 網域環境(DNS / DHCP / Certificate Authority)、Identity Management 機制、View Connection Server、View Composer Server、SMTP、RSA SecurID、WorkSpace、vRealize Operations……等。

    雖然建置 Horizon 虛擬桌面基礎架構,在相關伺服器角色上並沒有絕對的先後順序,不過在建構基礎架構時卻有相關的工法可供遵循,接下來我們將簡介本文整個 Horizon 基礎架構的安裝及設定流程:

    1. 安裝及組態設定 vSphere 虛擬化平台(ESXi、vCenter Server)。
    2. 建立 Windows AD(Active Directory)網域環境。
    3. 安裝及組態設定 View Connection 伺服器角色。
    4. 安裝及組態設定 SQL Server 資料庫。
    4. 安裝及組態設定 View Composer 伺服器角色,並且設定 Composer 資料庫連接事宜。
    5. 登入 Horizon View Administrator 管理介面,新增 Horizon 7 軟體授權。
    6. 新增 vCenter 及 Composer 伺服器角色。
    7. 組態設定 Event 資料庫。

    圖 2、Horizon 7 基礎架構運作示意圖



    建構 vSphere 虛擬化平台

    vCenter Server
    在 VMware Horizon 營運環境中,VMware 官方建議應該將擔任「管理」用途的 VM 虛擬主機,以及擔任 VDI 虛擬桌面的 VM 虛擬主機,分別採用「不同台」vCenter Server 分開進行管理,除了避免運作架構(例如,虛擬網路)複雜化之外,在管理思維上也可以避免 SPOF 單點失敗的影響,舉例來說,倘若管理 VDI 虛擬桌面環境的 vCenter Server 發生故障損壞事件,短期之間難以修復的話可以先讓管理環境的 vCenter Server 暫時接手管理作業。

    此外,雖然每台 vCenter Server 可以管理最多 2,000 台 ESXi 主機,以及 25,000 台運作中和 35,000 台註冊的 VM 虛擬主機,然而有鑑於組態配置及高可用性管理需求,最佳建議為「每個 Horizon Block」當中「每台」vCenter Server 管理數量 2,000 ~ 2,500 台 VDI 虛擬桌面。這樣的運作規模大小,建議採用的 vCenter Server 版本及資源配置如下:
    • Windows Server 2012 R2 或之後的版本。
    • VMware Virtual Hardware 11 或之後的版本。
    • vCenter Server 6.0 Update 1 或之後的版本。
    • 8 vCPU、24 GB vRAM、1 vNIC(VMXNET 3)、200GB vDisk(LSI Logic SAS)。

    圖 3、Horizon Pod 及 Block 運作架構示意圖


    ESXi Host
    在本文實作環境中,採用最新 vSphere ESXi 6.5.0 Update 1 版本,以便提供最新且穩定的虛擬化平台,並且屆時運作的 Horizon VDI 虛擬桌面,也將因為採用最新 ESXi 虛擬化平台,可以使用最新虛擬硬體版本獲得最大硬體資源及延展性。

    圖 4、採用最新 vSphere ESXi 6.5.0 Update 1 虛擬化平台版本

    此外,管理人員對於每台 ESXi 主機,能夠同時運作多少台 VDI 虛擬桌面應該非常好奇,然而應該怎麼估算每台 ESXi 主機能夠運作多少台 VDI 虛擬桌面。舉例來說,倘若我們希望每台 ESXi 主機,能夠同時承載 100 台 VDI 虛擬桌面時該怎麼估算,假設我們為每台 VDI 虛擬桌面配置 1 vCPU,並且使用 350 MHz的 CPU 運算資源,同時預估 vCPU 額外負載為 10 %

    在 ESXi 主機的部分,配置 2 顆 CPU 處理器且每顆處理器擁有 12 個運算核心,每個運算核心的時脈為 2.7 GHz,所以每顆 CPU 擁有 32.4 GHz 的運算能力,每台 ESXi 主機擁有 64.8 GHz 的運算能力,保留 ESXi 主機額外負載 10 %,保留 90 % 的運算能力也就是「58.32 GHz」。因此,每台 ESXi 主機在 CPU 運算能力資源方面,可以運作這樣的 VDI 虛擬桌面為「151 台」。

    同樣的,我們預計每台 VDI 虛擬桌面,運作 Windows 10 作業系統(32 位元)及使用 1920 x 1600 解析度,配置 4 GB 記憶體空間,每台 VDI 虛擬桌面的 vRAM 額外負載為 48.46 MB,未設定「Memory Reservation」記憶體空間預先保留機制。

    在 ESXi 主機的部分配置 512 GB 記憶體空間,保留 ESXi 主機及額外負載 10 % 之後,保留 90 % 的記憶體可用資源為 460.8GB。因此,每台 ESXi 主機在 Memory 記憶體資源方面,可以運作這樣的 VDI 虛擬桌面為「115 台」

    圖 5、VM 虛擬主機額外負載資訊


    vSphere Cluster
    在 Horizon VDI 虛擬桌面運作架構中,針對 vSphere Cluster 的部分會把「管理」用途及「VDI 虛擬桌面」用途分開,並且由「同台」或「不同台」vCenter Server 主機進行管理,舉例來說,建立第 1 個 vSphere Cluster 名稱為「Management」,在這個 vSphere Cluster 當中由多台 ESXi 主機組成,並運作所有擔任管理工作任務的 VM 虛擬主機,例如,View Connection Server、SQL Server…… 等。同時,除了其上運作應用服務建立高可用性機制之外,這個 vSphere Cluster 也必須啟用「vSphere HA」及「vSphere DRS」機制,以確保管理用途的 VM 虛擬主機所提供的服務具備高可用性。

    第 2 個 vSphere Cluster 名稱為「Desktop」,此 vSphere Cluster 由多台 ESXi 主機組成並且運作數百台 VDI 虛擬桌面主機。值得注意的是,在此 vSphere Cluster 中只會啟用「vSphere DRS」機制進行工作負載自動平衡機制即可,「不」建議啟用 vSphere HA 高可用性機制,原因在於每台 ESXi 主機已經運作許多 VDI 虛擬桌面主機,倘若啟用 vSphere HA 高可用性機制的話,當某台 ESXi 成員主機發生故障損壞的情況時,因為 vSphere HA 高可用性機制的緣故,將會造成其它台 ESXi 成員主機的工作負載瞬間加重,因此不建議開啟 vSphere HA 機制。

    第 3 個 vSphere Cluster 名稱為「3D Graphic Desktops」,此 vSphere Cluster 與第 2 個 VDI 虛擬桌面用途的主要差異在於,此 Cluster 中的 ESXi 成員主機有配置 GPU 顯示卡。事實上,在第 2 個 VDI 虛擬桌面主要用途為適合執行一般文書處理作業,或者是簡單的 2D 圖形處理,倘若嘗試開啟 3D 圖形時將會發生整個使用者操作體驗很差,原因在於必須透過 ESXi 主機的 CPU 運算資源來模擬及處理 3D 圖形作業。此時,採用安裝 GPU 顯示卡所建構的 VDI 虛擬桌面,便可以順暢執行 3D 圖形處理的工作任務,例如,Maya、AutoCAD、Solidworks…… 等,並且得到良好的使用者操作體驗。

    圖 6、vSphere Cluster 運作架構規劃示意圖


    Networking
    在 Horizon VDI 虛擬桌面運作架構中,擔任整個基礎架構的部份便是大家所熟悉的 vSphere ESXi 虛擬化平台,以及整個運作架構的管理中心 vCenter Server。倘若,運作環境中 ESXi 主機數量不多的話,那麼採用標準型交換器 vSS(vNetwork Standard Switch)的話,IT 管理人員可能還能夠負擔維運重任,但是 ESXi 主機數量眾多時,強烈建議採用分佈式交換器  vDS(vNetwork Distributed Switch),否則將會造成後續維運管理上很大的負擔及困擾,舉例來說,在具備 16 台 ESXi 成員主機的 vSphere Cluster 網路環境中,當需要變更某個虛擬交換器中連接埠群組(Port Group)名稱時,在 vDS 分佈式交換器環境中只要修改 1 次即可,但在 vSS 標準型交換器環境中就必須要逐台修改 16 次才行。

    此外,在每台 ESXi 主機上建議配置 2 張 1 Port 的 10 Gbps 網路卡,分別連接到不同台實體網路交換器上,以避免網路卡或網路交換器發生故障損壞事件造成 SPOF 單點失敗的問題,並且依據流量用途分別規劃出「4 種」Port Group,以便搭配 vDS 分佈式交換器中的 NIOC(Network I/O Control)網路流量管控機制,同時也便於管理人員掌握各種網路流量的傳輸情況以利故障排除作業:
    • Management: 負責 ESXi 主機的管理流量,建議網路流量共享層級及數值設定為 Normal 及 50。
    • VMNet: 管理用途的 VM 虛擬主機對外流量,以及 VDI 虛擬桌面對外提供服務的流量,建議網路流量共享層級及數值設定為 High 及 100。
    • Storage: Virtual SAN 或 iSCSI MPIO 儲存網路傳輸流量,建議網路流量共享層級及數值設定為 Normal 及 50。
    • vMotion: 用於 vSphere vMotion 線上即時遷移 VM 虛擬主機的傳輸流量,建議網路流量共享層級及數值設定為 Normal 及 50。

    圖 7、Horizon VDI 虛擬桌面網路流量規劃示意圖



    建立 Windows AD 網域環境

    以往在建構單純 vSphere 伺服器虛擬化環境時,可以選擇是否建置 Windows AD 網域環境。然而,在建構 Horizon VDI 虛擬桌面環境時,在許多應用情境當中 VDI 虛擬桌面採用 Windows 作業系統,因此「必須」要建置 Windows AD 網域環境,以便透過 Windows AD 網域的網域控制站 DC(Domain Controller),達成使用者身分「驗證(Authentication)/ 授權(Authorization)」的機制。

    建議採用的 Windows 網域控制站版本及資源配置如下:
    • Windows Server 2012 R2 或之後的版本。
    • VMware Virtual Hardware 11 或之後的版本。
    • 2 vCPU、6 GB vRAM、1 vNIC(VMXNET 3)、40 GB vDisk(LSI Logic SAS)。

    圖 8、使用者身份驗證及授權邏輯架構運作示意圖

    同時,在 Horizon VDI 虛擬桌面運作環境中,為了確保使用者登入時操作環境的一致性,便會使用「漫遊使用者設定檔」(Roaming User Profiles)的方式,在使用者登入 VDI 虛擬桌面時載入以便確保操作環境。

    在 Windows 使用者設定檔中有 3 種類型,分別是強制使用者設定檔(Mandatory User Profiles)、漫遊使用者設定檔(Roaming User Profiles)、本機使用者設定檔(Local User Profiles),然而不管哪種使用者設定檔中包含許多運作元件,例如,Local Data、User Data、User Registry……等。

    圖 9、使用者操作環境配置策略架構示意圖

    在本文實作環境中,將會建立名稱為 Horizon-VDI 的 OU 容器,並於其下再建立 VDI Users、VDI Computers 等 2 個子 OU 容器,以便屆時存放 VDI 虛擬桌面的使用者帳號及群組,以及 VDI 虛擬桌面的電腦帳戶,這樣設計 OU 設計優點在於方便後續套用 GPO 群組原則時,可以依照 OU 容器進行套用。當然,實務上管理人員可以在針對不同 VDI 虛擬桌面用途,建立更多的 OU 容器進行區隔以便進行更細緻的 GPO 群組原則。

    圖 10、建立 Horizon VDI 虛擬桌面專用 OU 容器



    建構 Connection 伺服器角色

    在 Horiozn 運作架構中 Connection Server,為負責擔任 VDI 虛擬桌面「代理人」(Broker)的角色,因為 VDI 虛擬桌面中的「代理程式」(Agent),隨時會將目前的運作狀態回報給 Connection Server,所以 Connection Server 將會得知每台 VDI 虛擬桌面的運作狀態,例如,桌面目前狀態為可用、更新中、重新啟動中……等。

    圖 11、單台 View Connection Server 運作架構示意圖

    在 VMware 最佳作法當中,每台 View Connection Server 最大支援 2,000 PCoIP / Blast Extreme 連線階段。因此,倘若建構的 Horizon 運作架構需要高可用性時,建議採用「N + 1」運作架構。「每台」View Connection Server 建議採用的版本及資源配置如下:
    • Windows Server 2012 R2 或之後的版本。
    • VMware Virtual Hardware 11 或之後的版本。
    • Horizon View 7.0 或之後的版本。
    • 4 vCPU、12 GB vRAM、1 vNIC(VMXNET 3)、40 GB vDisk(LSI Logic SAS)。

    圖 12、高可用性 View Connection Server 運作架構示意圖

    在本文實作環境中,採用最新 Horizon 7.2.0 的 View Connection Server 版本,在安裝流程中於安全選項頁面時,請選擇「Horizon 7標準伺服器」並勾選「安裝 HTML Access」項目,以便屆時也可以透過 HTML 網頁連接至 VDI 虛擬桌面,最後請確認採用「IPv4」通訊協定即可。

    圖 13、安裝 View Connection Server

    安裝完成後,雖然整個 Horizon VDI 虛擬桌面運作架構還在建構當中,但是因為 Connection Server 已經安裝完畢,所以可以先確認及登入至 Horizon Administrator 管理平台,以便確認 Connection Server 及相關服務正常運作。

    圖 14、登入 Horizon Administrator 管理平台



    建構 SQL Server 資料庫

    在 Horizon VDI 虛擬桌面運作架構中,SQL Server 資料庫將會用於存放「Composer Server」組態設定資料,以及屆時 Horizon 系統管理及 VDI 虛擬桌面的「Event」事件資訊。
    建議採用的 SQL Server 版本及資源配置如下:
    • Windows Server 2012 R2 或之後的版本。
    • SQL Server 2012 Standard SP2 或之後的版本。
    • VMware Virtual Hardware 11 或之後的版本。
    • 2 vCPU、8 GB vRAM、1 vNIC(VMXNET 3)、40 GB / 50 GB vDisk(LSI Logic SAS)。


    在本文實作環境中採用 SQL Server 2014 SP1 版本,並且分別建立 Composer Server 使用的「Composer-DB」資料庫,以及後續存放 Horizon VDI 事件用途的「Event-DB」資料庫。

    圖 15、建立 Composer Server 及 Event 用途的資料庫



    建構 Composer 伺服器角色

    在 Horiozn 運作架構中,透過 Composer Server「連結複製」(Linked Virtual Machine Clones)的運作機制,為每台 VDI 虛擬桌面主機建立「唯一指標」(Unique Pointers),因此每台 VDI 虛擬桌面主機所佔用的空間只會有「差異」的部份而已,與 Master Image 佔用空間相較之下通常可以減少 50 ~ 70 % 的空間大小。

    同時,在每個 Horizon Block 運作架構中,「每台」View Composer Server 會與 vCenter Server 進行配對,所以在運作架構上同樣以 2,000 個連線階段的最大值為最佳規劃。

    建議採用的 View Composer Server 版本及資源配置如下:
    • Windows Server 2012 R2 或之後的版本。
    • VMware Virtual Hardware 11 或之後的版本。
    • Horizon View Composer 7.0 或之後的版本。
    • 4 vCPU、12GB vRAM、1 vNIC(VMXNET 3)、40GB vDisk(LSI Logic SAS)。


    在本文實作環境中,採用最新 Horizon 7.2.0 的 View Composer Server 版本。值得注意的是,為了能夠順利將 Composer Server 的資料庫,指向至剛才所建立專用的 SQL Server 資料庫主機,所以必須先為 Composer Server 組態設定 ODBC,以便能夠將 Composer Server 資料庫指向至剛才所規劃的「Composer-DB」資料庫中。

    圖 16、為 Composer Server 組態設定 ODBC 資料庫連線工作任務



    新增 Horizon 7 軟體授權

    登入 Horizon 7 管理介面後,首先必須要新增 Horizon 7 軟體授權才行,否則後續將無法使用 Horizon 相關特色功能,例如,Composer、Instant Clone……等。請在 Horizon 管理介面中,依序點選「View 組態 > 產品授權及使用 > 編輯授權」後,填入你所擁有的 Horizon 7 軟體授權即可。

    圖 17、新增 Horizon 7 軟體授權



    新增 vCenter / Composer 伺服器角色

    當管理人員新增完 Horizon 7 軟體授權後,便可以準備新增 vCenter 及 Composer 伺服器資訊,以利後續 VDI 虛擬桌面的佈建作業。請在 Horizon 管理介面中,依序點選「View 組態 > 伺服器 >  vCenter Server > 新增」,在彈出的新增 vCenter Server 視窗中,填入 vCenter 伺服器管理者資訊。

    通過 vCenter 伺服器的驗證程序後,接著填入 Composer 伺服器的管理資訊,此實作環境中因為 Composer 伺服器,並未跟 vCenter 伺服器安裝在同一台主機中,因此選擇「獨立式 View Composer Server」選項。最後,在儲存空間頁面中詢問勾選是否啟用相關特色功能,例如「回收虛擬機器磁碟空間」「啟用 View 儲存加速器」,請管理人員依照運作架構環境需求勾選即可。

    圖 18、新增 vCenter 及 Composer 伺服器資訊



    組態設定 Event 資料庫

    在 Horizon 運作架構中,系統運作狀態及組態設定和 VDI 虛擬桌面運作資源,都會記錄於 Horizon Event 資料庫當中。然而,當你點選 Horizon View Administrator 管理介面中的「事件」項目時,將會發現無法看到任何事件記錄於其中,原因是必須先指定 Event DB 事件資料庫之後才行。在目前 Horizon 事件資料庫中,支援 Microsoft SQL Server 及 Oracle 資料庫。

    在本文實作環境中採用 Microsoft SQL Server 資料庫。請於 Horizon 管理介面中,依序點選「View 組態 > 事件組態 > 事件資料庫 > 編輯」,此時將彈出編輯事件資料庫視窗,請填入資料庫伺服器主機名稱或IP位址、連接埠、資料庫名稱...…等資訊,設定事件資料庫完成後,此時再度點選「事件」項目便可以看到相關事件,以幫助你進行故障排除任務。

    圖 19、組態設定 Horizon Event 事件組態資料庫





    結語

    透過本文的說明及實作相信讀者已經了解,在最新 Horizon 7 虛擬桌面解決方案當有哪些特色功能,能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 VDI 虛擬桌面運作環境。同時,我們討論如何規劃 Horizon 7 運作架構及資源管理的部分,最後進行實戰演練以便更深入了解整個運作架構及維運事務。

    前言

    日前 (2017/4/18),VMware 官方正式發佈 vSAN 第六代 VMware vSAN 6.6 Release 資訊。雖然距離上一版 vSAN 第五代 VMware vSAN 6.5 發佈才間隔短短五個月。但是,這次發佈的 vSAN 第六代總共新增 23 項特色功能!!

    有關過去每一代 vSAN 版本的新增特色功能資訊,請參考站長歷來撰寫的 vSAN 專欄文章:
    圖、VMware Virtual SAN版本演進及新增功能示意圖


    那麼,接下來站長將不定期針對第六代的 vSAN 6.6 深入剖析各項特色功能:

    【簡介】(Introduction)




    【安全性】(Security)




    【管理】(Management)

    在第 6 代 vSAN 版本當中,關於「管理」(Management)的部分共新增 11 項特色功能(如下所示),舉例來說,在過往的 vSAN 版本運作環境中,整個 vSAN 軟體定義儲存架構仍以 vCenter Server 管理平台為主,倘若 vCenter Server 發生故障損壞事件,或 vSphere Web Client 服務無法正常運作時,雖然不致影響運作在 vSAN 儲存資源上的 VM 虛擬主機,但是後續將無法進行任何管理動作,例如,觀看 vSAN 叢集節點主機的健康情況。

    VMware vSAN 6.6 Journey (3) - Management
    • Proactive Cloud Health Checks
    • vSAN Configuration Assist
    • vSphere Update Manager Integration (vSAN 6.6.1)
    • Highly Available Control Plane for Health Checks
    • Health and Performance Monitoring
    • Performance Diagnostics (vSAN 6.6.1)
    • vRealize Operations Management Pack for vSAN
    • Stretched Cluster Witness Replacement
    • Host Evacuation
    • Storage Device Serviceability (vSAN 6.6.1)
    • vSAN API and PowerCLI


    【部署】(Deployment)

    在第 6 代 vSAN 版本當中,關於「部署」(Deployment)的部分共新增 3 項特色功能(如下所示)。過去,在建構舊版 vSAN 軟體定義儲存運作環境時,最令 IT 管理人員感到困擾的便是建構的 vSAN 叢集中,所有 vSAN 叢集節點主機之間必須透過「多點傳送」(Multicast)進行溝通,並未支援企業及組織內部常用的「單點傳送」(Unicast)網路環境。

    VMware vSAN 6.6 Journey (4) - Deployment
    • Easy Install
    • Multicast Dependency Removed
    • Extensibility


    【可用性】(Availability)

    在第 6 代 vSAN 版本當中,關於「可用性」(Availability)的部分共新增 3 項特色功能(如下所示)。雖然,從第 2 代 vSAN 版本開始,vSAN 叢集便已經能夠建立「延伸叢集」(Stretched Cluster)的運作架構,然而新版 vSAN 6.6叢集環境能夠結合本地端故障保護機制,讓 vSAN 叢集站台之間的容錯機制更具彈性,甚至能夠結合親和性規則讓儲存原則的管理更具備靈活性。

    VMware vSAN 6.6 Journey (5) - Availability
    • Stretched Cluster Local Failure Protection
    • Stretched Cluster Site Affinity
    • Degraded Device Handling



    【效能】(Performance)

    在第 6 代 vSAN 版本當中,關於「效能」(Performance)的部分共新增 3 項特色功能(如下所示)。舉例來說,在新版 vSAN 6.6 叢集運作環境中,vSAN 叢集節點主機支援採用最新 Intel 3D XPoint NVMe 快閃儲存(Intel Optane P4800X)。此外,根據 VMware 官方進行的效能測試結果顯示,與舊版 vSAN 6.5 All-Flash 運作架構相較之下,新版 vSAN 6.6 All-Flash 架構整體儲存效能將能提升 50 % 或更高。

    VMware vSAN 6.6 Journey (6) - Performance
    • Deduplication and Compression
    • Rebuild and Resynchronization Enhancements
    • Checksum, De-Staging, iSCSI



    【軟體授權】(Software Licensing)

    倘若,企業及組織使用的是舊有 vSAN 版本的話,那麼可能會發現過需要使用進階版或企業版才能使用 All-Flash 全快閃儲存的運作架構,然而從第 5 代 vSAN 6.5 版本開始,所有 vSAN 軟體授權版本皆可以使用 All-Flash 全快閃儲存的運作架構,即使購買的是 ROBO(Remote Office / Branch Office),這種用於企業或組織遠端辦公室的軟體授權版本也支援,因此,即便是由 2 台 vSAN 節點主機所建構的小型 vSAN 運作環境,也能夠使用 All Flash 的硬體運作架構,為需要高 IOPS 儲存效能的分公司或小型 vSAN 環境提供解決方案。

    VMware vSAN 6.6 Journey (7) - Software Licensing
    • vSAN 6.6 Software Licensing



    【VMworld 2017 vSAN Session】