1. 基礎知識

　　1.1 高可用 (High Availability，簡稱 HA)

　　高可用性是指提供在本地系統單個組件故障情況下，能繼續訪問應用的能力，無論這個故障是業務流程、物理設施、IT軟/硬件的故障。最好的可用性， 就是你的一臺機器宕機了，但是使用你的服務的用戶完全感覺不到。你的機器宕機了，在該機器上運行的服務肯定得做故障切換(failover)，切換有兩個維度的成本：RTO (Recovery Time Objective)和 RPO(Recovery Point Objective)。RTO 是服務恢復的時間，最佳的情況是 0，這意味著服務立即恢復;最壞是無窮大意味著服務永遠恢復不了;RPO 是切換時向前恢復的數據的時間長度，0 意味著使用同步的數據，大于 0 意味著有數據丟失，比如 ” RPO = 1 天“ 意味著恢復時使用一天前的數據，那么一天之內的數據就丟失了。因此，恢復的最佳結果是 RTO = RPO = 0，但是這個太理想，或者要實現的話成本太高，全球估計 Visa 等少數幾個公司能實現，或者幾乎實現。

　　對 HA 來說，往往使用共享存儲，這樣的話，RPO =0 ;同時往往使用 Active/Active (雙活集群) HA 模式來使得 RTO 幾乎0，如果使用 Active/Passive 模式的 HA 的話，則需要將 RTO 減少到最小限度。HA 的計算公式是[ 1 - (宕機時間)/(宕機時間 + 運行時間)]，我們常常用幾個 9 表示可用性：

　　2 個9：99% = 1% * 365 = 3.65 * 24 小時/年 = 87.6 小時/年的宕機時間

　　4 個9: 99.99% = 0.01% * 365 * 24 * 60 = 52.56 分鐘/年

　　5 個9：99.999% = 0.001% * 365 = 5.265 分鐘/年的宕機時間，也就意味著每次停機時間在一到兩分鐘。

　　11 個 9：幾乎就是幾年才宕機幾分鐘。 據說 AWS S3 的設計高可用性就是 11 個 9。

　　1.1.1 服務的分類

　　HA 將服務分為兩類：

　　有狀態服務：后續對服務的請求依賴于之前對服務的請求。

　　無狀態服務：對服務的請求之間沒有依賴關系，是完全獨立的。

　　1.1.2 HA 的種類

　　HA 需要使用冗余的服務器組成集群來運行負載，包括應用和服務。這種冗余性也可以將 HA 分為兩類：

　　Active/Passive HA：集群只包括兩個節點簡稱主備。在這種配置下，系統采用主和備用機器來提供服務，系統只在主設備上提供服務。在主設備故障時，備設備上的服務被啟動來替代主設備提供的服務。典型地，可以采用 CRM 軟件比如 Pacemaker 來控制主備設備之間的切換，并提供一個虛機 IP 來提供服務。

　　Active/Active HA：集群只包括兩個節點時簡稱雙活，包括多節點時成為多主(Multi-master)。在這種配置下，系統在集群內所有服務器上運行同樣的負載。以數據庫為例，對一個實例的更新，會被同步到所有實例上。這種配置下往往采用負載均衡軟件比如 HAProxy 來提供服務的虛擬 IP。

　　1.1.3 云環境的 HA

　　云環境包括一個廣泛的系統，包括硬件基礎設施、IaaS層、虛機和應用。以 OpenStack 云為例：

　　

?

　　云環境的 HA 將包括：

　　應用的 HA

　　虛機的 HA

　　云控制服務的 HA

　　物理IT層：包括網絡設備比如交換機和路由器，存儲設備等

　　基礎設施，比如電力、空調和防火設施等

　　本文的重點是討論 OpenStack 作為 IaaS 的 HA。

　　1.2 災難恢復 (Disaster Recovery)

　　幾個概念：

　　災難(Disaster)是由于人為或自然的原因，造成一個數據中心內的信息系統運行嚴重故障或癱瘓，使信息系統支持的業務功能停頓或服務水平不可接受、達到特定的時間的突發性事件，通常導致信息系統需要切換到備用場地運行。

　　災難恢復(Diaster Recovery)是指當災難破壞生產中心時在不同地點的數據中心內恢復數據、應用或者業務的能力。

　　容災是指，除了生產站點以外，用戶另外建立的冗余站點，當災難發生，生產站點受到破壞時，冗余站點可以接管用戶正常的業務，達到業務不間斷的目的。為了達到更高的可用性，許多用戶甚至建立多個冗余站點。

　　衡量容災系統有兩個主要指標：RPO(Recovery Point Objective)和 RTO(Recovery Time Object)，其中 RPO代表 了當災難發生時允許丟失的數據量，而 RTO 則代表了系統恢復的時間。RPO 與 RTO 越小，系統的可用性就越高，當然用戶需要的投資也越大。

　　

?

　　大體上講，容災可以分為3個級別：數據級別、應用級別以及業務級別。

　　級別 定義RTOCTO

　　數據級 指通過建立異地容災中心，做數據的遠程備份，在災難發生之后要確保原有的數據不會丟失或者遭到破壞。但在數據級容災這個級別，發生災難時應用是會中斷的。

　　在數據級容災方式下，所建立的異地容災中心可以簡單地把它理解成一個遠程的數據備份中心。數據級容災的恢復時間比較長，但是相比其他容災級別來講它的費用比較低，而且構建實施也相對簡單。

　　但是，“數據源是一切關鍵性業務系統的生命源泉”，因此數據級容災必不可少。RTO 最長(若干天) ，因為災難發生時，需要重新部署機器，利用備份數據恢復業務。 最低

　　應用級 在數據級容災的基礎之上，在備份站點同樣構建一套相同的應用系統，通過同步或異步復制技術，這樣可以保證關鍵應用在允許的時間范圍內恢復運行，盡可能減少災難帶來的損失，讓用戶基本感受不到災難的發生，這樣就使系統所提供的服務是完整的、可靠的和安全的。RTO 中等(若干小時)中等。異地可以搭建一樣的系統，或者小些的系統。

　　業務級全業務的災備，除了必要的 IT 相關技術，還要求具備全部的基礎設施。其大部分內容是非IT系統(如電話、辦公地點等)，當大災難發生后，原有的辦公場所都會受到破壞，除了數據和應用的恢復，更需要一個備份的工作場所能夠正常的開展業務。 RTO 最小(若干分鐘或者秒)最高

　　1.3 HA 和 DR 的關系

　　兩者相互關聯，互相補充，互有交叉，同時又有顯著的區別：

　　HA 往往指本地的高可用系統，表示在多個服務器運行一個或多種應用的情況下，應確保任意服務器出現任何故障時，其運行的應用不能中斷，應用程序和系統應能迅速切換到其它服務器上運行，即本地系統集群和熱備份。HA 往往是用共享存儲，因此往往不會有數據丟失(RPO = 0)，更多的是切換時間長度考慮即 RTO。

　　DR 是指異地(同城或者異地)的高可用系統，表示在災害發生時，數據、應用以及業務的恢復能力。異地災備的數據災備部分是使用數據復制，根據使用的不同數據復制技術(同步、異步、Strectched Cluster 等)，數據往往有損失導致 RPO >0;而異地的應用切換往往需要更長的時間，這樣 RT0 >0。 因此，需要結合特定的業務需求，來定制所需要的 RTO 和 RPO，以實現最優的 CTO。

　　也可以從別的角度上看待兩者的區別：

　　從故障角度，HA 主要處理單組件的故障導致負載在集群內的服務器之間的切換，DR 則是應對大規模的故障導致負載在數據中心之間做切換。

　　從網絡角度，LAN 尺度的任務是 HA 的范疇，WAN 尺度的任務是 DR 的范圍。

　　從云的角度看，HA 是一個云環境內保障業務持續性的機制，DR 是多個云環境間保障業務持續性的機制。

　　從目標角度，HA 主要是保證業務高可用，DR 是保證數據可靠的基礎上的業務可用。

　　一個異地容災系統，往往包括本地的 HA 集群和異地的 DR 數據中心。一個示例如下：

　　

?

　　Master SQL Server 發生故障時，切換到 Standby SQL Server，繼續提供數據庫服務：

　　

?

　　在主機房中心發生災難時，切換到備份機房(總公司機房中心)上，恢復應用和服務：

　　

?

　　2. OpenStack HA

　　OpenStack 部署環境中，各節點可以分為幾類：

　　Cloud Controller Node (云控制節點)：安裝各種 API 服務和內部工作組件(worker process)。同時，往往將共享的 DB 和 MQ 安裝在該節點上。

　　Neutron Controller Node (網絡控制節點)：安裝 Neutron L3 Agent，L2 Agent，LBaas，VPNaas，FWaas，Metadata Agent 等 Neutron 組件。

　　Storage Controller Node (存儲控制節點)：安裝 Cinder volume 以及 Swift 組件。

　　Compute node (計算節點)：安裝 Nova-compute 和 Neutron L2 Agent，在該節點上創建虛機。

　　要實現 OpenStack HA，一個最基本的要求是這些節點都是冗余的。根據每個節點上部署的軟件特點和要求，每個節點可以采用不同的 HA 模式。但是，選擇 HA 模式有個基本的原則：

　　能 A/A 盡量 A/A，不能的話則 A/P (RedHat 認為 A/P HA 是 No HA)

　　有原生(內在實現的)HA方案盡量選用原生方案，沒有的話則使用額外的HA 軟件比如 Pacemaker 等

　　需要考慮負載均衡

　　方案盡可能簡單，不要太復雜

　　OpenStack 官方認為，在滿足其 HA 要求的情況下，可以實現 IaaS 的 99.99% HA，但是，這不包括單個客戶機的 HA。

　　2.1 云控制節點 HA

　　云控制節點上運行的服務中，API 服務和內部工作組件都是無狀態的，因此很容易就可以實現 A/A HA;這樣就要求 Mysql 和 RabbitMQ 也實現 A/A HA，而它們各自都有 A/A 方案。但是，Mysql Gelera 方案要求三臺服務器。如果只想用兩臺服務器的話，則只能實現 A/P HA，或者引入一個 Arbiter 來做 A/A HA。

　　2.1.1 云控制節點的 A/A HA 方案

　　該方案至少需要三臺服務器。以 RDO 提供的案例為例，它由三臺機器搭建成一個 Pacemaker A/A集群，在該集群的每個節點上運行：

　　API 服務：包括 *-api, neutron-server，glance-registry, nova-novncproxy，keystone，httpd 等。由 HAProxy 提供負載均衡，將請求按照一定的算法轉到某個節點上的 API 服務。由 Pacemaker 提供 VIP。

　　內部組件：包括 *-scheduler，nova-conductor，nova-cert 等。它們都是無狀態的，因此可以在多個節點上部署，它們會使用 HA 的 MQ 和 DB。

　　RabbitMQ：跨三個節點部署 RabbitMQ 集群和鏡像消息隊列。可以使用 HAProxy 提供負載均衡，或者將 RabbitMQ host list 配置給 OpenStack 組件(使用 rabbit_hosts 和 rabbit_ha_queues 配置項)。

　　MariaDB：跨三個階段部署 Gelera MariaDB 多主復制集群。由 HAProxy 提供負載均衡。

　　HAProxy：向 API，RabbitMQ 和 MariaDB 多活服務提供負載均衡，其自身由 Pacemaker 實現 A/P HA，提供 VIP，某一時刻只由一個HAProxy提供服務。在部署中，也可以部署單獨的 HAProxy 集群。

　　Memcached：它原生支持 A/A，只需要在 OpenStack 中配置它所有節點的名稱即可，比如，memcached_servers = controller1:11211,controller2:11211。當 controller1:11211 失效時，OpenStack 組件會自動使用controller2:11211。

　　

?

　　從每個 API 服務來看：

　　

?

　　

?

　　

?

　　關于共享 DB 的幾個說明 (主要來自 這篇文章)：

　　(1)根據該文章中的一個調查，被調查的 220 多個用戶中，200 個在用 Mysql Galera，20 多個在用單 Mysql，只有一個用 PostgreSQL。

　　(2)以 Nova 為例，Mysql 使用 Write-intent locks 機制來保證多個連接同時訪問數據庫中的同一條記錄時的互斥。以給新建虛機分配 IP 地址為例，該鎖機制保證了一個 IP 不會分給兩個用戶。

　　

?

　　(3)使用 Mysql Galera 時，所有節點都是 Master 節點，都可以接受服務，但是這里有個問題，Mysql Galera 不會復制 Write-intent locks。兩個用戶可以在不同節點上獲取到同一條記錄，但是只有一個能夠修改成功，另一個會得到一個 Deadlock 錯誤。對于這種情況，Nova 使用 retry_on_deadlock 機制來重試，比如@oslo_db_api.wrap_db_retry(max_retries=5, retry_on_deadlock=True)。默認都是重試 5 次。但是，這種機制效率不高。

　　該 HA 方案具有以下優點：

　　多主，零切換，方便地實現負載均衡

　　將 API 服務和 DB, MQ 服務無縫整合在一起

　　由于這些優點，該方案被大量采用。具體配置請參考 OpenStack High Availability Guide。

　　2.1.2 云控制節點的 A/P HA方案

　　需要的話，可以使用 Pacemaker + Corosync 搭建兩節點集群實現 A/P HA 方案。由主服務器實際提供服務，在其故障時由 Pacemaker 將服務切換到被服務器。OpenStack 給其組件提供了各種Pacemaker RA。對 Mysql 和 RabbitMQ 來說，可以使用 Pacemaker + Corosync + DRBD 實現 A/P HA。具體配置請參考 OpenStack High Availability Guide。

　　該 HA 方案的問題是：

　　主備切換需要較長的時間

　　只有主提供服務，在使用兩個節點的情況下不能做負載均衡

　　DRBD 腦裂會導致數據丟失的風險。A/P 模式的 Mysql 的可靠性沒有 Mysql Galera 高。

　　因此，可以看到實際部署中，這種方案用得較少，只看到 Oracel 在使用這種方案。

　　2.2 Neutron HA

　　Neutron 包括很多的組件，比如 L3 Agent，L2 Agent，LBaas，VPNaas，FWaas，Metadata Agent 等 Neutron 組件，其中部分組件提供了原生的HA 支持。這些組件之間的聯系和區別：

　　

?

　　2.2.1 原生 HA 方案

　　Neutron 提供了多種原生的 HA 方案：

　　(1)L2 Agent HA： L2 agent 只在所在的網絡或者計算節點上提供服務，因此它是不需要HA的。

　　(2)L3 Agent HA

　　L3 Agent 比較特殊，因為它是所有 openstack (core)services 中唯一一個有狀態的，因此，不能使用傳統的在多個節點上部署多個實例使用LB來做HA。Neutron 本身的調度器(scheduler)支持在多個網絡節點上部署多個L3 Agent，但是，由 L3 Agent 管理的 Virtual Router 自身需要有HA的實現。它的HA的Neutron 原生實現包括如下幾種方式：

　　(a)Juno 中引入的 Automatic L3 Agent Failover (當 VR 所在的 L3 Agent 失效的時候，Neutron 自動將它 failover 到其它某個 L3 Agent 上)

　　該方案增加了一個配置項 allow_automatic_l3agent_failover。當它的值為 True 時，L3 plugin 去周期性地檢查所有有管理 Virtual Router 的 L3 Agent 的狀態。如果某 L3 Agent 死了，受它管理的 Router 會重新被 schedule 到別的 L3 Agent 上。 Neutron L3 Plugin 通過判斷該 L3 Agent 是否在規定時間(agent_down_time)內有發回心跳消息來判斷它是否活著。存在多種 L3 Agent 未能及時上報心跳但是 router 依然在轉發網絡包的可能。因此這種實現可能會存在 L3 Agent 被認為死了但是其 router namespace 依然在轉發網絡包和響應 ARP 請求而導致的問題。如果網絡后端不阻止死掉了的 agent 使用 route 的 IP 地址，那新老 namespace 就可能存在沖突。這種沖突不會斷掉 E-W 網絡，因為新老 namespace 中的一個都可以承擔無狀態網絡包的轉發任務。然后，南-北網絡可能會受影響，因為 NAT 只存在于一個router 上。而且，reschedule 后，浮動 IP 也會無法工作，因為它們與 router 的 外部端口的綁定關系不會被設置到新的router 上。

　　這種方案要求使用多個網絡控制節點，每個節點上運行一個 L3 Agent。在某個 Agent 死了時，Router 會被部署到別的 Agent 上。這種方案，除了上述的問題外，切換時間過長是其主要問題。

　　(b)Juno 中引入的 VRRP (Virtual Router Redundancy Protocol)方案 (由 VRRP/Keepalived 控制 VR 的 VIP 和 VMAC 的 failover)

　　該方案使用多余一個的網絡控制節點，提供 A/P HA。其主要特點為：

　　

?

　　(c)Juno 引入的 DVR

　　該方案將 NAT 和 L3 Agent 部署到虛機所在的計算節點，在網絡控制節點上只部署 DHCP 和 SNAT。該方案解決了 L3 Agent 和 Metadata Agent 的 H/A 問題。目前，將 DHCP Agent 改成分布式，VPNaas 以及 FWaas 的修改工作已經在進行中。用戶需要使用第三方軟件提供 SNAT 的 HA 方案。

　　(3)DHCP Agent 的 HA

　　DHCP 協議自身就支持多個 DHCP 服務器，因此，只需要在多個網卡控制節點上，通過修改配置，為每個租戶網絡創建多個 DHCP Agent，就能實現 DHCP 的 HA 了。

　　

?

　　(4)Metadata agent 和 proxy 的 HA

　　跟 metadata service 相關的組件包括：

　　neutron-ns-metadata-proxy：作為一個獨立的進程運行在 master virtual router 的 network namespace 中。它接受由 qrouter 通過 iptables 控制轉交的 instance 訪問 metadata service 的 request。

　　neutron-metadata-agent：Neutorn 的組件之一，運行在Neutorn 網絡節點上，通過本地 socket 和 neutron-ns-metadata-proxy 進程通信，其配置文件是 /etc/neutron/metadata_agent.ini;它會通過 http(s) 和 Nova metadata service 通信;它通過 RPC 和 neutron-server 通信。你還可以通過配置 metadata_workers 的值來運行多個獨立的進程。

　　nova metadata api：這個和 nova api 類似，是 nova 的 API 的一部分，通常使用的端口是 8775。它接收neutron-metadata-agent 的request。

　　從 HA 角度來講：

　　neutron-ns-metadata-proxy 的 HA 不需要單獨考慮，因為它受 Virtual router 控制。

　　neutron-metadata-agent：需要和 neutron-ns-metadata-proxy 通過soket 通信，因此，簡單地，可以在所有 neutron network 節點上都運行該 agent，只有 virtual router 所在的L3 Agent 上的 neutron-metadata-agent 才起作用，別的都standby。你可以在多個網絡節點上啟用該服務。

　　nova metadata api：同 nova api 一樣是無狀態服務，可以部署在那個階段上，使用 HAProxy 做 A/A HA。

　　

?

　　(注意，因為虛機在啟動過程中需要訪問 qrouter，這也就是說，要求虛機所在的子網必須已經添加到了一個 Virtual router 上，否則，它是無法通過 qrouter 走的，除非走 qdhcp)

　　或者更詳細地看出完整的路徑(圖中紅色線條，從VM開始，到 NOVA-API Metadata 結束)：

　　

?

　　(5)LBaas Agent HA

　　目前 Neutron LBaaS 代理服務是無法通過其自帶的 HAProxy 插件 實現高可用的。實現 HAProxy 高可用常見的方案是使用 VRRP (Virtual Router Redundancy Protocol ，虛擬路由冗余協議)，不過 LBaaS HAProxy 插件目前還不支持該協議。因此，只能使用 Pacemaker + 共享存儲(放置 /var/lib/neutron/lbaas/ 目錄) 的方式來部署 A/P 方式的 LBaas Agent HA，具體請參考 這篇文章 中描述的方法。

　　2.2.2 使用 Pacemaker 實現 A/P HA

　　使用 Pacemaker + Corosync 搭建兩節點(或者多節點) A/P 集群。在主節點上，由 Pacemaker 啟動 Neutron 的各種服務。

　　2.2.3 小結

　　從上面可以看出，除了 DHCP Agent 天生就通過配置可以實現 A/A HA 以及 L3 HA 以外，其它的組件的 HA 都是 A/P 的，而且實現的技術可以是原生的，也可以使用 Pacemaker，也可以結合起來使用。比如 RDO 的方案：

　　

?

　　2.3 存儲控制節點 HA

　　這里只討論 cinder-volume。

　　(1)在使用非共享存儲時，cinder-volume 進程受 Pacemaker 監控，在其停止的時候重啟。這種方案下，存儲控制節點宕機的話，上面的所有卷都會損失掉。因此，在生產環境中，必須使用下一種方案。

　　(2)在使用共享存儲時，考慮到目前代碼中存在的資源競爭(參考這里)，該服務只能實現為 A/P HA 方式，也就是說在某個時刻，只有主節點上的 cinder-volume 在運行。RedHat 這個 ticket 中有具體的分析。目前，cinder-volume 還沒有內在的 HA 實現，只能借助第三方軟件比如 Pacemaker。A/A 的實現在 Liberty 中正在進行，請 參見 這個和 這個。

　　

?

　　2.4 計算節點和虛機 HA

　　在測試環境中，我們常常將虛機創建在本地磁盤上，那么，在機器宕機的話，這些虛機將永遠也回不來了。因此，在生產環境中，需要將虛機部署在 cinder-volume 或者共享的存儲比如 RDB 或者 NFS 上。這樣的話，在虛機損壞時，可以從共享存儲上將其恢復(使用 nova evacuate 功能)。 使用 Pacemaker 部署 A/P 方案(類似 2.3 中 cinder-volume A/P HA)的話，生產環境中計算節點的數據往往遠遠超過 Corosync 集群中節點數目的限制。

　　業界有幾個解決方案：

　　(1)Controller 節點通過管理網 Ping 所有 Compute 節點，Controller 節點檢查nova service-list，對出問題的節點 Evacuate

　　特征：太簡單粗暴，容易引起誤殺和數據損壞

　　(2)Pacemaker-remote： 突破Corosync的集群規模限制，

　　特征：啟用多個心跳網時，處理策略單一，引起用戶業務不必要的中斷

　　(3)集中式檢查

　　

?

　　(4)分布式健康檢查

　　

?

　　OpenStack 的各提供商中，就該需求，RadHat 使用的是上述的第二種方案，具體方案在 計算節點HA 方案：

　　部署方式如下：

　　使用 Pacemaker 集群作為控制平面

　　將計算節點做為 Partial members 加入到 Pacemaker 集群中，受其管理和監控。這時候，其數目不受 Corosync 集群內節點總數的限制。

　　HA 實現細節：

　　Pacemaker 通過 pacemaker_remote 按照順序(neutron-ovs-agent -> ceilometer-compute -> nova-compute) 來啟動計算節點上的各種服務。前面的服務啟動失敗，后面的服務不會被啟動。

　　Pacemaker 監控和每個計算節點上的 pacemaker_remote 的連接，來檢查該節點是否處于活動狀態。發現它不可以連接的話，啟動恢復(recovery)過程。

　　Pacemaker 監控每個服務的狀態，如果狀態失效，該服務會被重啟。重啟失敗則觸發防護行為(fencing action);當所有服務都被啟動后，虛機的網絡會被恢復，因此，網絡只會短時間受影響。

　　當一個節點失效時，恢復(recovery)過程會被觸發，Pacemaker 會依次：

　　運行 ‘nova service-disable’

　　將該節點關機

　　等待 nova 發現該節點失效了

　　將該節點開機

　　如果節點啟動成功，執行 ‘nova service-enable’

　　如果節點啟動失敗，則執行 ‘nova evacuate’ 把該節點上的虛機移到別的可用計算節點上。

　　其中：

　　步驟(1)和 (5)是可選的，其主要目的是防止 nova-scheduler 將新的虛機分配到該節點。

　　步驟(2)保證機器肯定會關機。

　　步驟(3)中目前 nova 需要等待一段較長的超時時間才能判斷節點 down 了。Liberty 中有個 Blueprint 來添加一個 Nova API 將節點狀態直接設置為 down。

　　其余一些前提條件：

　　虛機必須部署在 cinder-volume 或者共享的臨時存儲比如 RBD 或者 NFS 上，這樣虛機 evaculation 將不會造成數據丟失。

　　如果虛機不使用共享存儲，則必須周期性地創建虛機的快照并保存到 Glance 中。在虛機損壞后，可以從 Glance 快照上恢復。但是，這可能會導致狀態或者數據丟失。

　　控制和計算節點需要安裝 RHEL 7.1+

　　計算節點需要有防護機制，比如 IPMI，硬件狗 等

　　小結： OpenStack 云/網絡/存儲 控制節點 HA 集群

　　

?

總結

以上是生活随笔為你收集整理的openStack高可用性和灾备方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。