文章

目前顯示的是 八月, 2017的文章

Google Cloud Launch 的 Percona 服務介紹

圖片
Database一直是每一項服務需要特別花心思的地方,通常將資料庫服務委託給Google CloudSQL是最簡單不過的,不過,如果希望能夠保有對資料庫的完整操控權,則自建Database是最快的選擇... 而Google Cloud Launcher服務即有DB Cluster的建置,在此以Percona Cluster為例,透過Cloud Launcher簡單的建置Percona MySQL Cluster… Percona是分支自MySQL的資料庫,相較於原生MySQL,Percona原生提供了更多的資料庫工具,讓使用者可以更快速的建置自己的MySQL應用... 首先,我們先到Cloud Lancher ( https://console.cloud.google.com/launcher ) 搜尋”Percona”關鍵字,然後進入Percona的說明頁面之後點選LAUNCH ON COMPUTE ENGINE... 依照GCP上的建議,Percona Cluster 預設啟動的機器不能小於三台,我們可以指定資料庫的zone位置,也可以依照需求指定更多的主機數量... 選好機器的zone和數量後,只要點選Deploy,就可以開始進入開通cluster的動作... 建立完成後可以在”Deployment Manager”裡,看到您剛剛建立的Percona,裡面會有每一台機器的說明、DB的password、相關說明文件等資料 由於Cloud Launcher是以Appliance的方式提供服務,也就是會使用Compute Engine來建置,因此我們會看到剛剛所開立起來的三台機器... 在Percona的Cluster機制下,所有的主機都是可以讀寫的狀態... 因此,接下來我們可以使用SSH進入機器內檢視,登入後,執行mysql指令連線所建立的資料庫,若執行成功就能開始使用... 為了求證cluster的運作,以下進行幾個簡單測試.. 1.每一台DB資料是否會同步? 答案是會~ 在第一台建立一個Database,其他二台會自動sync,如附圖 2.關掉一台,其他台能不能正常運作? Step1. Shutdown最後一台機器,在percono1新

GCE上實作Bastion Gateway的HA架構

圖片
概念 NAT(或稱Bastion主機)的架構在自建機房中常常可以見到,我們也可以將該架構在雲端環境上建置來使用... 而Google雲端的環境中,可以透過network與routing的方式搭配來建置一個具有HA(High Availability)的NAT環境,讓NAT不是單點提供服務... 下面是架構的簡單描述: 建置過程 設定網路與防火牆基本規則 首先,建議使用自建Network,好處是可以自訂內部的路由與相關防火牆規則,且可以避免影響其他主機。 gcloud compute networks create kankan-ha-nat \     --mode legacy \     --range 10.10.10.0/24     為了可以測試狀態,我們允許port 22的ssh連線,因此建立允許 tcp 22 port 連線的防火牆規則... gcloud compute firewall-rules create kankan-ha-nat- allow -ssh \ --allow tcp:22 --network kankan-ha-nat 在NAT server的建置上,我們需要讓內外部連線可以透通,因此將tcp:1-65535, udp:1-65535, icmp等協定打開,讓內部的網段( 10.10.10.0/24) 可以透過NAT server來連線外部網路。 gcloud compute firewall-rules create kankan-ha-nat- allow -internal \ --allow tcp:1-65535,udp:1-65535,icmp \ --source-ranges 10.10.10.0/24 --network kankan-ha-nat 建立NAT server 然後我們將NAT server建立起來: gcloud compute instances create nat-gateway-asia-east1-a --network kankan-ha-nat --can-ip-forward \ --zone asia-east1-a \ --image-family debian-8 \ --image-project debian-cloud \ --tags nat 為

透過hosts來指定domain對應的ip位置

某些時候,我們會需要透過DNS的方式來對應外部服務的domain name位置,而某些應用中,這些domain name可能在不同的環境會對應到不同的地方,此時,我們在傳統作業方式會透過/etc/hosts的編輯方式來讓該主機可以對應到外部服務位置.... 而在K8S中,從1.7之後的版本開始支援hosts的複寫功能... 首先,我們需要先知道對應的DNS與IP有哪些,然後可以透過hostAliases這個spec來描述ip與hostname的對應,下面是個簡單的範例,以nginx的主機為例,如果掛載hostAliases的話,則可以預期在主機內可以觀察到/etc/hosts內有所希望複寫的功能... hosts . yaml apiVersion : v1 kind : Pod metadata:  name : hostaliases - pod spec:  hostAliases:   - ip : "127.0.0.1"    hostnames:     - "foo.local"     - "bar.local"   - ip : "10.1.2.3"    hostnames:     - "foo.remote"     - "bar.remote"  containers:   - name : cat - hosts    image : nginx 接著我們可以把上面的hosts.yaml檔案透過create建立起來... # kubectl create -f hosts.yaml pod "hostaliases-pod" created 最後,我們可以實際登入pod中檢視內部的/etc/hosts的對應狀況... # kubectl exec -it hostaliases-pod bash root@hostaliases - pod :/# root@hostaliases - pod : /# cat / etc / hosts # Kubernetes-managed hosts file. 127.0 . 0.1 localho

資料庫搬到Cloud SQL - 使用AWS DMS服務

圖片
Google CloudSQL提供高品質的資料服務,但在使用之前,一般大家會問到該怎麼把資料庫搬到CloudSQL的環境,CloudSQL提供透過 Cloud Storage來做 import/export,如果再資料量不是很大的狀況下,直接針對資料庫做 export 然後存放到 Cloud Storage後,再 import 到 CloudSQL 的速度還滿快的... 但是如果需要做到持續同步資料,則我們會需要一些規劃與工具來持續同步您的資料。 AWS DMS在資料轉移上是一個不錯的選擇,透過簡單的設定流程,可以快速的備份你的資料從一個Database到另一個Database,這裡以MySQL與CloudSQL為例,給大家參考: 建立步驟如下: Step1 建立Replication Instances Step2 Replication Instances建好之後會給一組IP address,將這組IP加入你的DB network DMS:    另外,GCE需要加入DMS的IP: Cloud SQL 加入DMS的IP: Step3 建立source、target的Endpoints Step 4 建立Tasks 指定從哪一個source到哪一個target,要 migrate哪個database哪些table。 建立完成後,若沒有錯誤資料就會開始備份... 情境測試: 1.測試Table內有特殊設定的欄位 有sequence的Table 結果: 轉到Cloud sql上,設定會不見,要再自己加入 有fk的Table 結果: 轉到Cloud sql上,設定會不見,要再自己加入 有timestamp的Table 結果: 轉到Cloud sql上,設定會不見,要再自己加入 2.轉10000筆& 100000筆的時間差?   如果是直接從DMS上做Migrate existing data,5分鐘內資料就會sync到目的端;若是用Replicate data changes only,一筆一筆sync時間就會拉的比較長。 3.當schema相同,加入異動資