怎麼制定一套合適的伺服器命名方案

藍楓紫葉發表於2014-08-13
伺服器

在MNX上，我們一直致力於為我們的雲託管服務建立一個全新的資料中心。起初我們是一家提供管理Linux服務的諮詢公司，這也就意味著我們將置身於大量的不同使用者環境，以及已有的與之同等數量的裝置命名方案…這些並非都是好的。這個問題可以回溯到計算機出現的時候，每個人都有自己最佳的選擇來命名主機。起初，絕大多數的方案都是好的，但是很快隨著基礎裝置的擴充套件以及時間的推移就變得臃腫不便。

由於我們啟用了全新的資料中心，於是想要提出自己的命名方案來解決在別處出現過的常見問題。我們從各個方面吸收想法，比如說大型企業公開的資料，有關該主題的各種各樣RFC草案，數不勝數的部落格/論壇帖子。將他們所有都考慮進去，我們制定了一套最佳方案，那就是應該為中小企業命名自己的硬體而服務。

XKCD似乎在每個主題都涉及到了

permanence

首先，我將先回顧一下現有的命名方案，包括他們的一些亮點和我們做出選擇的理由。

A Records（A記錄）

在開始之前，為每個主機命名（通過適用於你作業系統的方法）並設定它的DNS A Records為從一個詞，該詞是從一個列表隨機選擇的：

雖然有許多詞庫可供選擇，但是我們推薦的特定詞列表來自於Oren Tirosh的記憶編碼專案。該專案特定選擇的1633個詞都是比較短的（只有4-7個字母），而且相互之間讀音上也不同，在電話中就能很容易理解，同時這也是國際上普遍認同的。這些助記詞彙列表應該是不易出現拼寫錯誤，當與更多結構化名稱比較時可以轉換字元。我們在這些詞彙上花費了大量的時間和研究，他們的特點很符合我們的要求。

本來，主機名不應該暗含任何有關主機的用途和功能，但是與一個永久性的名稱不同的是，作為標記一塊特定硬體部分的唯一標識，將貫穿它整個生命週期（當硬體損壞後不再對其重新命名）。該命名方式應該是物理上用來標記裝置，且將極大方便運維工程師，遠端管理，記錄儲存。這也是反向解析域名的PTR記錄所應解決的。

CNAME　Records（別名記錄）

其次，指派一個或多個DNS別名來掩蓋有關裝置有用的功能細節，比如說地理位置，環境，工作部門，用途等等。這些所有的資訊都將在你的CMDB（配置管理資料庫）中記錄下來並且能夠方便地引用。

別名記錄是開發者應該瞭解並用於組合服務。當你需要一個主機名時，保證這些命名結構的一致性將減少記住該主機名所需的腦力勞動。

Standardized CNAME Structure（標準化別名結構）

在你開始註冊域名是，要將每一條附加資訊分割成一個適當的子域名。DNS是按分層設計的，因此充分利用這個分層結構將會使我們受益。

Specify Geography（指定地理位置）

域名註冊之後，新增一條有關主機地理位置的子域名。使用基於該主機資料中心位置的五個字元的UN/LOCODE（聯合國貿易和交通位置編碼值）。這比那些諸如IATI（國際航空運輸協會）編碼能覆蓋更多特定的位置，而且它還是定義良好的標準。

在大多數的情形中，你可以去掉包含2個字元的國家程式碼那部分，僅僅使用餘下3個字元的位置程式碼。也就是說，你可以只使用nyc.example.com 而不是nyc.us.example.com，除非你在多個國家都有資料中心，而且這些位置碰巧使用了有衝突的程式碼。

Specify Environment（指定所屬環境）

接下來，指定主機所屬環境的某一部分：

  • dev – Development
  • tst – Testing
  • stg – Staging
  • prd – Production

這些應該都要遵循任何你釋出的管理過程模型…你或多或少有一些名稱的，類似於像沙箱，實訓環境等等…

Specify Purpose and Serial Number（指定用途和編號）

然後，我們指定主機的功能所屬的基本範疇，並且附加上一個編號

  • app – Application Server (non-web)
  • sql – Database Server
  • ftp – SFTP server
  • mta – Mail Server
  • dns – Name Server
  • cfg – Configuration Management (puppet/ansible/etc.)
  • mon – Monitoring Server (nagios, sensu, etc.)
  • prx – Proxy/Load Balancer (software)
  • ssh – SSH Jump/Bastion Host
  • sto – Storage Server
  • vcs – Version Control Software Server (Git/SVN/CVS/etc.)
  • vmm – Virtual Machine Manager
  • web – Web Server

對於編號來說，基於你預期的長度使用補零。計劃是有擴充套件的，但通常2個數字就已經綽綽有餘了。

編號按順序增加並且在一個特定的資料中心基於服務型別對編號進行劃分，而不是一個全域性唯一的索引。那就意味著你可能在多個資料中心都有一個web01。

Convenience Names（易記的名字）

除了標準化的結構之外，你也許為了方便會增加額外的別名記錄，比如webmail,cmdb,puppet等詞。

Special Cases（特別的情形）

Networking and Power Equipment（網路和能源裝置）

對於網路和能源裝置來說，硬體就決定了它們的用途，它也不可能不經過重新配置就移動。瞭解了這些，忽視掉隨機詞的命名約定，並使用功能性縮寫來描述DNS A record：

  • con – Console/Terminal Server
  • fwl – Firewall
  • lbl – Load Balancer (physical)
  • rtr – L3 Router
  • swt – L2 Switch
  • vpn – VPN Gateway
  • pdu – Power Distribution Unit
  • ups – Uninterruptible Power Supply

…你也可能會想獲得資料中心的地理位置資訊。如果需要，你仍可以為像這些核心/硬碟，公有還是私有等特定資訊新增別名記錄。

Secondary and Virtual IP Addresses（輔助的虛擬IP地址）

輔助的虛擬IP地址（用於高可靠性，Web服務，網路遷移，VLAN標籤通訊等等）的微妙之處在於它們可能是流動性，並不會繫結到硬體的某一部分。既然如此，直接向DNS分配一個功能性名稱就變得很容易，而且遵循了常規的命名習慣。

Mail and Name Servers （郵件和名稱伺服器）

對於你的郵件和名稱伺服器來說，由於MX和NS記錄不能指向別名，你需要利用DNS A records。也就是說，你可以擁有多個DNS A record，因此繼續正規表示式，並且為了能利用公共的MX和NS記錄新增另外的一些東西。

DNS Configuration（DNS配置）

由於每個資料單元我們都使用合適的DNS子域名，因此我們可以在每臺主機上配置搜尋域，這樣就可以只管理屬於他們自己本地範疇的裝置。

當裝置運作的時候就變得很方便了，因為你可以利用較短的主機名，比如，當與一個資料中心通訊的時候，使用ping sql01 而不是它的全稱ping sql01.prd.nyc.example.com。

一般來說，我們的命名方案也允許你為了防止只是隨機短的主機名的公開而造成意外的資訊洩漏，而在網際網路上對功能性的名稱進行單獨的分解。這有點像隱藏式安全，但總歸是考慮到這方面了。（注意，如果你也想隱藏“特例”的命名約定你需要對此進行微調）

Private Network and Out-of-Band Addressing（私有網路和界外定址）

你也可以充分利用內建的DNS解析來顯示私有的網路地址和界外/IPMI/iDRAC地址。該域名應該匹配另一部分記錄，但再一次，利用一個恰當的子域名。注意，最佳的實踐表明不要使用偽造的TLD（頂級域名），因為ICANN（網際網路名稱與數字地址分配機構）可以在任何時候登記它們，那麼整合網路的時候將變得更棘手。

完整的命名方案樣例

Capacity（功能）

該命名方案可以很方便地支援1500+個全域性伺服器。如果有更多的伺服器，你可以為隨機名稱加入地理位置資訊部分，然後再使用列表中的詞彙。缺點在於crimson.nyc.example.com可能會與crimson.pdx.example.com具有完全不同的目的，因此還是有一點內在的障礙。或者，你可以擴充套件最初的詞彙列表，試著新增一些類似於助記詞編碼的詞彙。

如果你管理著10000+的伺服器，主機極可能只有一個單獨的模組用途，因此，忽視以上我們所講的所有東西，只需要使用基於位置或者功能性命名方案就可以了。

Tip & Tricks（建議和技巧）

  • 如果在你的環境中它是一個技術用語，你應該從助記編碼詞彙列表中去除易混淆的詞彙，比如像’email’。
  • 保證用途縮寫詞長度上的一致性，並經常進行編號填充匹配（也就是說，不要在某些地方使用01而在其他地方使用1，一般在所有地方都要使用較長的01）
  • 你所使用的實際用途的縮寫詞並不重要，只要選定一個方案，確保它是在檔的，並堅持使用它。
  • 很容易保證用途縮寫詞稍微的廣義性，因為更多的細節資訊可以從你的CMDB（配置管理資料庫）獲取。
  • 不論如何，所有的資訊都應該儲存在CMDB中而且易於訪問。
  • 當因為邏輯設定多個別名記錄，記住你設定的記錄越多，你需要維護的就多。
  • 儘可能地自動化。
  • 我們已經寫了一個名為genhost的短指令碼，它可以幫助你隨機選擇並記錄你曾使用過的主機名詞彙。

總結

我們的伺服器命名方案降低了因為記錄裝置情況，連線伺服器和直接維護合適的硬體記錄所需的腦力勞動。裝置的某些部分很可能隨著時間的變化而改變，他們也只會包含在別名記錄中。那就意味著如果一個伺服器當掉了，你不需要去在其他的裝置上更新對那臺伺服器的引用，因為你可以僅僅更新別名記錄，讓它指向一個新的主機就可以了。儘管我們的方案在開始時增加了一些複雜性，但他能夠很好地平衡易用性，可維護性以及與支援長期增長之間的關係。

相關文章