欄目導航

新聞資訊

新聞資訊

服務器規劃

10.4.7.200
10.4.7.11
10.4.7.12
10.4.7.21
10.4.7.22

配置服務器(不特殊聲明->代表操作所有服務器)

修改主機名

hostnamectl set-hostname hdss7-11.host.com
hostnamectl set-hostname hdss7-12.host.com
hostnamectl set-hostname hdss7-21.host.com
hostnamectl set-hostname hdss7-22.host.com
hostnamectl set-hostname hdss7-200.host.com

更改網絡配置

vi /etc/sysconfig/network-scripts/ifcfg-ens33

(7-11)
TYPE=Ethernet
BOOTPROTO=none
NAME=ens33
DEVICE=ens33
ONBOOT=yes
IPADDR=10.4.7.11
NETMASK=255.255.255.0
GATEWAY=10.4.7.254
DNS1=10.4.7.254

(7-12)
TYPE=Ethernet
BOOTPROTO=none
NAME=ens33
DEVICE=ens33
ONBOOT=yes
IPADDR=10.4.7.12
NETMASK=255.255.255.0
GATEWAY=10.4.7.254
DNS1=10.4.7.254

(7-21)
TYPE=Ethernet
BOOTPROTO=none
NAME=ens33
DEVICE=ens33
ONBOOT=yes
IPADDR=10.4.7.21
NETMASK=255.255.255.0
GATEWAY=10.4.7.254
DNS1=10.4.7.254

(7-22)
TYPE=Ethernet
BOOTPROTO=none
NAME=ens33
DEVICE=ens33
ONBOOT=yes
IPADDR=10.4.7.22
NETMASK=255.255.255.0
GATEWAY=10.4.7.254
DNS1=10.4.7.254

(7-200)
TYPE=Ethernet
BOOTPROTO=none
NAME=ens33
DEVICE=ens33
ONBOOT=yes
IPADDR=10.4.7.200
NETMASK=255.255.255.0
GATEWAY=10.4.7.254
DNS1=10.4.7.254

關閉selinux

vim /etc/selinux/config
SELINUX=disabled

關閉防火墻

systemctl stop firewalld
systemctl disable firewalld
systemctl enable firewalld

安裝epel-release

yum install -y epel-release
或者
curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo

安裝必要的工具

yum install wget net-tools telnet tree nmap sysstat lrzsz dos2unix bind-utils -y

7-11上安裝bind9 (dns解析)

安裝

yum install -y bind

配置bind (主配置文件)

vim /etc/named.conf

vi /etc/named.conf

listen-on port 53 { 10.4.7.11; };
ipv6的一行干掉
allow-query     { any; };
forwarders      { 10.4.7.254; };
dnssec-enable no;
dnssec-validation no;

使用命令檢查配置:
named-checkconf

如圖(特別注意格式):

區域配置文件

vim /etc/named.rfc.1912.zones

zone "host.com" IN {
        type  master;
        file  "host.com.zone";
        allow-update  { 10.4.7.11; };
};

zone "od.com" IN {
        type  master;
        file  "od.com.zone";
        allow-update  { 10.4.7.11; };
};

如圖:

區域數據文件

vim /var/named/host.conf.zone

$ORIGIN host.com.
$TTL  600    ; 10 minutes
@       IN   SOA  dns.host.com.  dnsadmin.host.com. (
                  2021092501     ; Serial
                  10800          ; Refresh
                  900            ; Retry
                  604800         ; Expire
                  86400          ; Negative Cache TTL
                  )
            NS  dns.host.com.
$TTL  60    ; 1 minutes
dns             A       10.4.7.11
HDSS7-11        A       10.4.7.11
HDSS7-12        A       10.4.7.12
HDSS7-21        A       10.4.7.21
HDSS7-22        A       10.4.7.22
HDSS7-200       A       10.4.7.200

vim /var/named/od.com.zone

$ORIGIN od.com.
$TTL  600    ; 10 minutes
@       IN SOA  dns.od.com. dnsadmin.od.com. (
                2021092502     ; Serial
                10800          ; Refresh
                900            ; Retry
                604800         ; Expire
                86400          ; Negative Cache TTL
                )
            NS  dns.od.com. 
$TTL  60    ; 1 minutes
dns             A       10.4.7.11
harbor          A       10.4.7.200

測試

Apache Mesos 是 Apache 基金會下的一個分布式資源管理框架，它被稱為是分布式系統的內核。Mesos 結合容器化技術提供了有效的，跨分布式應用或框架的資源隔離和分享機制，可以做為 Hadoop、Mpi、Hypertable、Spark、 Elasticsearch 等各種分布式應用的資源管理平臺。網絡上已經有很多關于 Mesos 架構及分配策略的文章博客，這里我將拋開這些基本原理，從實踐的角度出發，暢談 Mesos 的生態圈。我會結合 Marathon、 Chronos、Jenkins、 Spark 等在 Mesos 上的使用實踐來介紹人們是如何基于 Mesos 來搭建容器應用分發管理，CI/CD 測試，運維管理以及大數據平臺的，同時我也會嘗試辯證的分析 Mesos 在上述實踐中的利弊。

從去年到現在，我一直在開發基于 Mesos/Docker 的數人云產品，整個團隊對 Mesos/Docker 及其周邊的工具都在關注及使用中，所以積累了一定的實踐經驗。目前網上已經有很多關于 Mesos 架構及分配策略的文章，以前我也分享過關于 Mesos 持久化存儲的技術。這里我就不再討論Mesos的原理了，我會從實踐的角度出發，聊一下利用 Mesos 我們可以做什么，以及在使用 Mesos 搭建各種平臺時，有什么坑，當然，這些坑也不全是我自己碰到的，有一些是其他使用Mesos的伙伴總結出來的。

另外，因為內容比較多，我計劃把這個分享做成一個系列，這次我首先簡單介紹一下可以運行在Mesos之上的框架，然后主要圍繞 Marathon、 Mesos、 Docker、 Chronos 這幾個關鍵詞展開本次分享。

首先通過一張圖來介紹都有哪些軟件可以或者必須運行在Mesos之上，然后，探討如何圍繞 Marathon、, Mesos、 Docker 搭建一個PaaS 平臺，以及其中遇到的問題。

Frameworks On Mesos

這張圖是我摘自Mesosphere官網的關于運行在 Mesos 上的不同 Framework。其中不同顏色代表了不同類型的應用。

藍色：支持運行 Long-Running 的應用，我們就是基于這些工具來搭建 PaaS 平臺的
綠色：大數據處理的工具，這些工具是搭建大數據平臺的基礎
紫色：批處理工具，利用批處理工具可以搭建一個基本的持續集成平臺，尤其是 Jenkins
紅色：大數據存儲的工具，其中Cassandra 是無中心分布式存儲的，Es 是一個基于Apache Lucene(Tm)的開源搜索引擎除此之外，比較常見的工具還有
Singularity: 同時支持運行 Long-Running 應用與批處理 Job

如何將應用部署到 Mesos 平臺

無論是開源的應用還是我們自己開發的python，Java等應用，目前主要有三種方式來讓應用使用 Mesos 資源池里面的資源。我們可以通過下圖來看一下:

Frameworks-On-Mesos/Native

這種方式就是為你的應用開發相應的調度組件來調用 Mesos 的 Api 接口(應用的 Scheduler)，同時包裝你應用的 Executor，將其下發到 Mesos－Slave 上運行, 并且我們一般會將應用的 Scheduler 通過 Marathon 部署，這樣可以利用 Marathon 的特性來保證應用 Scheduler 的高可用。譬如，Cisco Sponsored 的開源項目 Elasticsearch On Mesos 就是通過這種讓 Es 做為Framework 運行在 Mesos 上的。還有 Myriad/Yarn-On-Mesos。這種方式優點是可定制程度高，可以使用 Mesos 的各種特性，譬如動態保留，持久化存儲，超售等。缺點是這種方式工作量比較大, 額外增加了開發負擔。

將應用的模塊拆解并 Docker 容器化/Long-Running

然后將這些模塊各自獨立的發布到 Marathon 上，當然 Docker 容器化并不是必須的，但是為了降低環境依賴，避免在 Slave 機器上裝過多的東西，我們最好還是容器化。以 Hdfs 為例，我們將 Hdfs-Namenode, 與 Hdfs-Datanode 做為 Marathon 的兩個 App 部署到 Mesos 上，并通過 Constraints 和環境變量來設置兩者通信，相較于 Mesosphere 的 Hdfs-On-Mesos(Hdfs 作為框架運行于 Mesos 之上)，這種方式看上去很low，沒有 Mesosphere 的方式優雅，但是在實際使用過程中，運維更喜歡將 Namenode，Datanode 分清楚，單獨部署的方式，畢竟運維需要了解軟件的架構。Mesosphere 的框架方式隱藏掉了 Hdfs 的細節，部署方便，但同時也增加了 Debug 的難度。所以說這個需要權衡。

批處理

這種方式比較直觀，不再介紹。

下面結合 PPT 中的圖片簡單介紹下 Es-On-Mesos的架構，首先我們需要將 Es 的調度器部署到 Mesos-Master 或者某臺機器上，并注冊到 Mesos-Master 上，從而 Es 的調度器就會收到 Mesos-Master Offer 的資源，Es 的調度器接受了資源后就會將Es的執行器（和Es的節點）部署到相應的 Mesos-Slave 機器上；接下來，Es 的節點實例會通過注冊到 Zookeeper 集群來發現彼此；進而，Es 組成了一個集群了。為了保證 Es 運行到 Mesos 上，我們看到實際上社區做了很多改造。

Myriad/Yarn-On-Mesos 也使用了類似的做法來將 Yarn 部署到 Mesos 集群上，額外需要注意的是，部署成功后，Nm與Rm就可以繞開Mesos-Master直接通信了。另外，如果一個公司只是使用 Yarn，那么這種做法非常雞肋，但是如果追求 Yarn 與其他應用的資源混用，那么就有意義。

PaaS

PaaS 想要解決的問題簡單說就是讓用戶關注自己的應用，PaaS服務提供方負責解決應用的高可用及失敗重啟的問題。前面我們已經提到過，利用Mesos，Marathon，Docker等相關的技術可以搭建一個PaaS平臺，同時，通過開發一些插件，并結合持續集成，我們可以通過這個PaaS平臺為用戶解決很多問題。另外，我們可以認為這一套PaaS平臺的用戶就是開發者，維護方就是 Devops。這里是一個基本完善的基于 Marathon 的 PaaS 平臺需要的東西:

Marathon
Mesos
私有的Docker 鏡像倉庫，建立自己公司的私有Docker倉庫是非常有必要的，首先是國外的官方鏡像源太慢，其次是公司有安全性的考慮。
Jenkins，這個我們前面提到過，利用jenkins搭建持續集成環境，這里將是開發與運維交接應用的地方，我們可以認為jenkins的輸入就是開發在Github上提交的代碼，Jenkins的輸出就是 Docker 鏡像，然后通過Marathon部署到Mesos上對外提供服務，Jenkins輸出部分無需開發Touch。
Github／Gitlab，或者其它的代碼控制倉庫，這個相信大家都明白，開發需要它來做代碼版本控制，好多時候Jenkins也需要它來做構建的觸發器。
Metrics，Metrics, Metrics!!! 重要的事情說三遍。無論是Marathon還是Mesos，在可視化監控方面還都有所欠缺。有很大的定制開發工作量，這也是Mesosphere正在干的活。關于Metrics，我們后面細聊。
日志歸檔，以及Debug的問題，通過Marathon部署分布式應用與單機部署應用很大的不同就是增加了Debug的難度，分布式應用由于其異步性，沒有全局時鐘，應用日志在全局看是亂序的。這為日志的歸檔，基于日志的審計，以及基于日志的Debug都帶來了很大難度。

Marathon

相信很多同學已經了解 Marathon，因為這幾乎成為了Mesos的標配，我這里只簡單介紹下它的一些比較關鍵的技術點。作為一個PaaS工具，Marathon在UI方面沒有商業版的好，譬如Heroku，Tutum等。我們在使用Marathon時，需要自己額外定制一些東西，譬如根據Metrics進行Scale等，這些我們后面會講到。

Marathon是集群的Init.D，應用的啟動器。
盡管Mesos有自己容器化技術，我仍然推薦使用Docker，Mesos自己的容器化技術仍然沒有解決環境依賴問題，還需要在宿主機上安裝一些東西。但是Docker可以解決這個問題。
擴展方便，這也是借了容器化的東風。相較于虛擬化，容器鏡像更小，同時啟動也更快。這里需要注意的是，對于Docker來說，Docker容器啟動快，并不代表Docker容器里承載的服務啟動快。以一個Java程序為例，雖然Docker容器已經run起來，其實，里面的Java程序還需要一段時間去加載。 Docker容器是無法感知到程序的初始化狀態的。
利用Marathon可以實現藍綠部署。這里Marathon只負責啟動藍，綠兩個環境，這其中容錯，流量切換等還需要應用自身支持才行。
Restfulapi，Marathon的Restful接口非常完善，我平時都是通過它來完成操作的。
再一個就是利用Haproxy做服務發現，和負載均衡。

使用Marathon，我們可以：

在通過Marathon部署我們的應用時，我們不再需要Supervisord，使用Health Check代替Supervisord效果會更好。Marathon支持基于Tcp和Http協議的健康檢查，它的大體邏輯是Marathon會周期性的掃描應用的健康檢查路徑，如果響應時間連續n次超出閾值，那么Marathon會直接重啟這個應用。這就是我們所說的 Fastfailed，只要應用響應過慢，我們就應該殺掉它，因為響應過慢的應用會大大拖慢全局服務的響應速度。我們不再需要容器內部的失敗重啟，應該直接殺掉容器。
Constraints: 通過Constraints，我們可以限制應用部署在指定的一臺或者幾臺slave機器上，這類應用一般是有狀態應用，或存儲型應用，必須將應用的數據目錄掛載出來的情況下；又或者應用需要部署在有特殊配置的Slave機器上，譬如，應用需要使用Gpu資源，而只有特定的幾臺機器有Gpu資源時。
Resources: Resources 與 Constraints 的不同在于Resources是可以量化的。所以Resources的切分粒度要比Constraints更細，而Constraints對資源的量化只有0或1兩種。所以使用Resource時會更靈活，隨之而來的問題時，只有 CPU、內存、端口、帶寬等可以量化，其它的資源我們可能需要為Mesos集成資源的量化模塊支持。
Force Pull Image：可以每次部署應用時強制拉取一次 Docker 鏡像。考慮到性能損耗的問題，我不推薦這種做法，更好的辦法是拉取配置。
Docker Image 的預熱：為了縮短應用的部署時間，最好是先把Image Pull到Slave機器上，同時可以避免 Marathon 因鏡像下載問題頻繁發布應用，如果使用內網的Registry時鏡像的拉取問題可以不用考慮。另外有人提到通過網絡存儲部分解決鏡像的拉取問題。
應用部署的數量上來之后，瓶頸在Zookeeper。實際使用中，成千上萬個應用實例在Marathon上頻繁的失敗重啟會導致Zookeeper阻塞，具體原因跟Zookeeper的性能有關。

Private Docker Registry

搭建私有鏡像倉庫是必須的，網上也已經有很多關于私有鏡像倉庫的搭建方法了，我這里只說一下需要重點考慮的幾點，

第一個就是存儲策略。一般來說，我們需要為我們的Registry準備數據盤，并提前規劃好大小，特別要注意的是要把Inode設置大些，Docker小文件比較多。這個可以借助一些開源的工具來做，比如，Devicemapper就有相應的格式化工具。另一個就是存儲的Driver，現在比較常見的是Devicemapper，Aufs，這兩個之間的優劣可以參照數人云的FAQ或者我的博客。一般建議Centos用Devicemapper，Ubuntu用Aufs。
第二個就是權限管理的問題，運維為了控制Registry的Size，我們可以配置registry為有權限的Push，和無權限的Pull。這樣也解決了Slave的部署問題，同時又不會導致Registry的大小失控。
最后一個就是我們最好為Registry配置一個Frontend，這樣便于維護，搜索，和刪除無用的Docker Images。

Docker

關于Docker，有兩點需要注意的：

第一個是Docker鏡像的制作方式。我們可以認為一般有兩種 Docker 鏡像制作方式，第一種就是制作一個Docker的Base Image，然后在啟動時動態拉取可執行程序；第二種，基于程序的的Release版本來做Docker Image的Tag。這兩種方式都可以，第二種方式更直觀一些，只是增加了些運維成本，需要定時回收老的Tag。
第二尤其要注意的是異常退出的Docker容器回收問題。目前Mesos可以設置定時回收他自己容器Garbage，但是無法回收異常退出的Docker容器。Marathon不停重試發布異常的應用會導致磁盤被壓爆。

服務發現

目前在 Mesos 社區常見的有如下三種服務發現方式

Mesos-DNS

Mesos-DNS 仍在緊鑼密鼓的開發之中，Mesos-DNS 是無狀態的，可以自由的Replica，所以我們可以通過為每個Slave部署Mesos-DNS 的方式來保證高可用；同時，Mesos-DNS 支持Restfulapi，調用方便。通過下圖我們可以大致看出 Mesos-DNS 通過監聽 Mesos-Master 來將發現的服務地址生成DNS解析，（并同步到外部的DNS服務器，如有必要），內部的服務發現就可以直接通過內部的DNS解析來保證。

Bamboo/Haproxy

基于 Bamboo/Haproxy 的服務發現技術使用十分廣泛，Bamboo通過監聽Marathon來動態的更新Haproxy里面的服務映射。與 Mesos-DNS 類似， Haproxy 也是無狀態的并且支持 Restfulapi ，局限是Bamboo只能通過監聽Marathon來進行應用的服務發現。

一容器一IP

作為 Mesos 當中的一容器一 IP 機制，其設計目標之一在于建立一套可插拔架構，允許用戶從現有第三方網絡供應商處選擇解決方案并作為網絡實現基礎。對此作者沒有過多研究，摘抄官方的架構圖及組件解釋：

負責為即將啟用的容器指定IP 要求的框架/調度標簽。這是一項可選服務，能夠在不帶來任何副作用的前提下將一容器一 IP 能力引入現有框架當中。
由一個 Mesos Master 節點與一個 Mesos Agent 節點共同構建的 Mesos 集群。
一套第三方IP 地址管理（簡稱 IPam）服務器，負責根據需要進行 IP 地址分配，并在 IP 地址使用完畢后將其回收。
第三方網絡隔離方案供應程序負責對不同容器系統加以隔離，并允許運維人員通過配置調整其可達性及路由方式。
作為輕量級 Mesos 模塊被加載至 Agent 節點當中的網絡隔離模塊將負責通過調度程序進行任務要求審查，同時利用 IP 地址管理與網絡隔離服務為對應容器提供 IP 地址。在此之后，其會進一步將IP地址交付至 Master 節點以及框架。雖然 IP 分配與網絡隔離功能完全可以由單一單元負責實現，不過立足于概念層面，Mesos 提供了兩項不同的服務方案。其一設想由兩家彼此獨立的服務供應程序分別提供IP地址管理與網絡隔離服務。舉例來說，其中之一利用 Ubuntu Fan 實現 IP 地址分配，而另一方則利用 Calico 項目進行網絡隔離。

受此啟示，筆者正在嘗試將 Docker-Weave 集成到現有的 Paas 平臺當中來。

負載均衡

這里主要探討 Mesos-DNS 和 Haproxy 的負載均衡。我可能不應該把 Mesos-DNS 作為負載均衡放在這里，DNS 與負載均衡還是有點兒不同的。我們可以認為Mesos-DNS只有roundrobin（或者隨機轉發）的負載均衡策略，而 Haproxy 的負載均衡策略就比較多了，除 Roundrobin 之外，Haproxy 還支持最小鏈接，IP哈希等多種策略。另外，需要提到的是， Mesos-DNS 與 Haproxy 都支持配置的動態加載。

調度

我這里的調度指的是PaaS平臺應該按什么策略將應用部署到哪一臺Slave上，這里我特別想拿Docker-Swarm 的調度策略來與Mesos的調度策略做對比，兩者的的調度策略切入點，或者說維度非常不一樣。前者是從Docker的角度出發，而后者由于更Generic，是從資源的角度出發。如果純從使用Docker來說， Docker－Swarm的策略更給力。

Docker-Swarm 對容器的調度已經相當豐富：

通過參數 Constraint 將容器發布到帶有指定label的機器上。譬如將 Mysql 發布到Storage==SSD 的機器上來保證數據庫的IO性能；

通過參數 Affinity 將容器發布到已經運行著某容器的機器上，或者已經Pull了某鏡像的機器上；

通過參數 Volumes-From, Link, Net 等將容器自動發布到其依賴的容器所在的機器上；

通過參數 Strategy 可以指定 Spread，Binpack和random 3種不同 Ranking Node 策略，其中 Spread 策略會將容器盡量分散的調度到多個機器上來降低機器宕機帶來的損失，反之binpack策略會將容器盡量歸集到少數機器上來避免資源碎片化，Random策略將會隨機部署容器。

由于Mesos 更加 Generic，其在容器調度方面稍顯欠缺，目前我們可以通過設置主機Attribute或者Resources的限制來將容器調度到指定的機器上。下面是Resource 和 Attributes的相關例子。

Resource:

Cpus:24;Mem:24576;Disk:409600;Ports:[21000-24000,30000-34000];Bugs(Debug_Role):{A,B,C}’

Attributes:

‘Rack:Abc;Zone:West;Os:Centos5;Level:10;Keys:[1000-1500]’

Metrics&Auto-Scaling

對于PaaS平臺來說，監控是必不可少的，而這也恰好是Marathon/Mesos欠缺的，需要很多的定制開發。一般來說，我們需要從三個維度：物理主機層面、Docker 層面和應用業務層面來立體監控。物理主機層面的監控方案已經非常成熟；Docker層面的監控一般是使用Cadvisor或Sysdig等監控軟件；應用層的業務邏輯監控需要與業務綁定。另一個問題就是自動擴展，首先明確下自動擴展的定義，我們可以認為自動擴展就是根據業務負載動態的調整資源。自動擴展主要包括下面三個問題：

自動擴展的觸發器: 由于自動擴展是依賴于業務的，所以說觸發器也是依賴于具體場景的。譬如說根據CPU或者內存的Metrics負載，或者根據App的請求失敗率，又或者如果我們已經預估了每天的訪問高峰，那么就可以用定時觸發的機制。
怎樣擴展：一般來說，自動擴展分為兩層，Iaas層與應用層: Iaas層一般需要調用Iaas層的Api去增加或者減少機器資源；而應用層則是通過調用Marathon的Api去伸縮應用實例。
彈性/擴展策略: 增加或者減少多少資源是一個需要不斷優化的問題。簡單點，我們可以根據實際業務制定固定的資源擴展粒度，并逐步調整；更高級一點就是引入機器學習的方法，根據歷史負載動態確定資源擴展的Size。

Log&Debug

前面我們已經提過，分布式應用與普通應用不同，其日志分布在多臺未知的機器上。所以我們需要將日志采集到一個地方來集中管理。目前比較常見的日志方案是Elk，這里主要說一下Docker的日志問題。收集Docker里面應用的日志主要有兩種方法：

將應用的日志輸出到 Stdout/Stderr,對于這種方式我們可以通過 Logspout/Heka 來采集日志：這種方式在Docker異常退出時會丟掉部分應用日志。
將應用的日志輸出到固定目錄并通過-V 命令掛載出來，對于這種方式，我們可以通過 Logstash 采集宿主機固定目錄的日志。

作者簡介

周偉濤，數人科技技術總監/研發總監嘉賓介紹：現數人科技云平臺負責人，曾就職于國際開源解決方案供應商 Red Hat，紅帽認證工程師， Mesos contributor，高級 Python 開發工程師。是國內較早一批接觸使用Docker，Mesos等技術的開發者。

責任編輯

魏偉，關注Docker，CSDN Docker專家群匯聚眾多頂級專家學者，歡迎加入，搜索微信“k15751091376”拉入。

本文為CSDN投稿，請點擊

閱讀原文

查看完整文章并參與討論

如果您喜歡這篇文章，請點擊右上角

…

將本文分享給你的朋友

欧美vvv,亚洲第一成人在线,亚洲成人欧美日韩在线观看,日本猛少妇猛色XXXXX猛叫

服務器規劃

配置服務器(不特殊聲明->代表操作所有服務器)

7-11上安裝bind9 (dns解析)