Pohsien Workspace

ActiveMQ 5 在 High Availability (HA) 上分成兩種角色: master 和 slave ，類似 Active-Standby mode。在一般情況只會有 master 處理 Request，slave 待命，只有當 master 異常時，slave 才會接手這些動作。

一般 ActiveMQ 都是把資料存在記憶體裡面，但是當 Broker 掛掉後，記憶體裡存放的 Message 會消失，因此在 HA 的概念就是要想辦法把 Message 變成 Persistent Data 存在 Disk，然後當 Broker 恢復時或是其他 Broker 接手時，可以直接存取這個 Persistent Data 來接手處理 Message。

ActiveMQ 5 HA 分成兩種方式:

• Shared File System Master Slave (Share Filesystem)
• JDBC Master Slave (Share Database)

本篇文章主要會探討的是 ActiveMQ 5 的 Shared File System Master Slave 模式。

最近因工作關係剛好研究到 MariaDB High Availability (HA) 機制，因此本篇整理一下 MariaDB Master-Slave Replication 的相關筆記。

在一個系統環境裡，資料庫通常扮演著很重要的角色，主要負責存放系統的一些紀錄或是使用者的資料，因此資料庫的備援/高可用性 (High Availability)以及負載平衡 (Load Balancing) 就變得相當重要。

目前 MariaDB 針對 High Availability 有以下常見的幾種方式:

• Master-Slave Replication (A-S Mode)
• Master-Master Replication (A-A Mode)
• Galera Cluster Master-Master (A-A Mode)
• Galera Cluster Master-Slave (A-S Mode)

本篇文章主要會探討的是最傳統的方式 Master-Slave Replication 。

不知不覺一年又過了，又到了年底回顧及審思的時間。

2021 算是個人比較混亂的一年，不管是工作還是個人上，覺得今年整體都蠻混亂，工作上的問題比較多，導致沒辦法切割拿捏生活跟工作，所以今年都比較封閉一點，連部落格都停擺。不過還好到年底慢慢穩定下來，且有機會好好休息，能夠停下腳步好好審視今年，並為 2022 做準備。

不過不管如何，2021 年都順利結束，明年繼續加油。

2021 回顧

2020 回顧

2020 年真的是讓人印象深刻的一年，因為新冠肺炎影響關係，許多計畫都被影響，但就整體上來看，今年對我個人來說仍然算是一個蠻有收穫的一年，做了許多嘗試以及達各種成就。

工作方面

今年初換了新公司，算是一個新的開始，雖然忙到炸裂，進去還沒過試用期，就忙到好像過了好幾年一樣，但卻是忙得有意義，非常充實。

此系列文為 E2E Testing for Kubernetes 的介紹，如尚未看過前一篇文章，可以參考底下連結:

• E2E Testing for Kubernetes (Part I) - kubetest
• E2E Testing for Kubernetes (Part II) - Comformance Testing

Conformance Testing

在前一篇文章裡，我們介紹到如何使用 kubetest 執行 Kubernetes E2E Test ， kubetest 會使用 Kubernetes Binary 開啟新的乾淨 Cluster 去做測試。在這一篇文章裡我們會介紹如何對自己部署的 Cluster 做 E2E Test。

現今 Kubernetes Cluster 部署方式越來越多種，部署門檻也越來越低，但是在部署完之後要如何確認自己的 Cluster 真的是正常可用的？ 大多數的人(包含筆者以前)都是簡單部署一些 Deployment 或是 Service 看是否有 running 就認為 Cluster 是正常的，或是部署時沒有看到什麼錯誤訊息就覺得沒事，但是這樣是不太足夠的，因為有可能壞掉的是一些不常使用的功能或是人工比較難已發現的問題，這樣之後如果使用者部署應用時剛好使用到相關功能，發生問題將會很難查找。

為了確認 Cluster 功能是否正常，我們可以針對 Cluster 做完整的測試，測試各個API是否正常，但是筆者查了一下發現網路上比較少關於 Kubernetes 測試的詳細資訊，因此花了一點時間研究並紀錄在此系列文章。

注意， Kubernetes 的測試有非常多種層面，例如： Unit Testing 、 Integration Testing 、 E2E Testing 、 Performance/Benchmark Testing 、 Load Testing 、 Stress Testing 或是 Security Testing，但是在此系列文中，強調的是測試 Cluster 的功能是否正常，因此重點會放在 E2E Testing 上。

E2E Testing for Kubernetes:

• End-to-End Testing for Kubernetes (Part I) - kubetest
• End-to-End Testing for Kubernetes (Part II) - Comformance Testing

Log Rotate意思是當log隨著時間擴大後，能夠自動打包壓縮或是清除掉舊log，以免系統空間被log吃光。

ELK Filebeat並無支援log rotate的功能，Beats主要功能是做log shipping，不包含log rotate，因此需要透過額外的方式做。

這次是第一次參加iThome Kubernetes Summit，當初看到早鳥票釋出就直接買了($2400左右)，以一天的Conference來說不算便宜，但是能夠去學習學習增廣見聞也是值得的。

結果買票之後才得知我們社群Cloud Native Taiwan User Group(CNTUG)也有去擺攤，雖然是付費票，但是還是去支援了一下社群攤位xD。

上午場都在跟附近社群交流、逛攤位以及顧社群攤位，因此只聽了第一場「賣K8s 的人不敢告訴你的事」。下午花比較多的時間在聽議程，以下列出部分議程的簡單心得跟筆記。

這篇主要是測試Enterprise PKS佈出來的Kubernetes Node 上面的硬碟滿了會造成什麼影響以及要如何解決。其實這個問題應該跟一般Kubernetes環境差不多，只是目前有一些case緣故還是需要在Enterprise PKS環境下測試一下。因此特別針對這部分做測試。

PKS全名是Pivotal Container Service，顧名思義是由Pivotal這間公司開發的。Pivotal是VMware的子公司，也許比較少人知道這間公司，不過相信大家應該都聽過tomcat或是redis，這兩個知名的專案就是由Pivotal開發的，由此可知Pivotal也是一家技術非常扎實強大的公司。

PKS介紹

PKS是用來管理/部署Kubernetes Cluster的一個平台，由於目前Kubernetes在建置或維運上還是需要蠻高的成本及技術門檻，為了要降低維運成本，讓企業能完全專注在自己的服務上，因此才漸漸開始有了這類管理/部署Kubernetes的平台出現。透過這種平台能夠輕鬆的部署Kubernetes Cluster，有些平台甚至還針對Kubernetes Cluster提供HA、Fault Tolerance或是Load Balancing的機制，大大降低維運成本，而PKS就是其中一種這種平台(產品)，類似的其他產品還有Rancher、Redhat OpenShift以及IBM Cloud Private等。