Tag: balancing

NLB 接 ALB？

在 AWS API Changes 上看到這個修改：「2021/09/27 - Elastic Load Balancing - 3 updated api methods」。

說明是這樣：

Adds new ALB-type target group to facilitate forwarding traffic from NLB to ALB

所以是 NLB 可以接到 ALB 嗎，這看起來讓彈性變大不少...

Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443

Cloudflare 推出了 Wrap 服務：「Want to try Warp? We just enabled the beta for you」。

本地端的 web server 可以只開 127.0.0.1:{80,443}，然後 Wrap 的程式會連到 Cloudflare 上面接 web request 回來打到你本地端的電腦上，官方舉的例子用 port 8080：

$ cloudflare-warp --hostname warp.example.com http://localhost:8080

然後也支援多台機器接同一個 hostname (load balancing，順便做 high availability)：

$ cloudflare-warp --hostname warp.example.com --lb-pool origin-pool-1 http://localhost:8080

對於安全架構多了一些選擇可以用...

AWS PrivateLink

AWS 計畫把先前設計的 VPC Endpoint 都併到 AWS PrivateLink 裡，統一管理：「New – AWS PrivateLink for AWS Services: Kinesis, Service Catalog, EC2 Systems Manager, Amazon EC2 APIs, and ELB APIs in your VPC」。

Today we are announcing AWS PrivateLink, the newest generation of VPC Endpoints which is designed for customers to access AWS services in a highly available and scalable manner, while keeping all the traffic within the AWS network. Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager (SSM), and Elastic Load Balancing (ELB) APIs are now available to use inside your VPC, with support for more services coming soon such as Key Management Service (KMS) and Amazon Cloudwatch.

這樣就不用弄 proxy server 然後在上面管一堆 policy 了... (先不講自己搞 HA 的麻煩事，光是有些程式還得 patch 才能支援 proxy 就會想翻桌了 XD)

大型 WordPress 站台會用到的 LudicrousDB (以及 HyperDB)

最近收到 HyperDB 的 mailing list 信件 (開頭是「[HyperDB] How can I set up HyperDB with latest version.」這封)，有人提到 HyperDB 很久沒更新了... 結果在信理看到有人回了「stuttter/ludicrousdb」這個專案：

LudicrousDB is an advanced database interface for WordPress that supports replication, failover, load balancing, & partitioning

兩個專案都是抽換掉 WordPress 在處理 database 的 library，然後希望自己控制 master/slave 的讀寫分離以及各機房之間的處理 (還有 replication lag)，而不要靠 ProxySQL 這類工具來做 (以時間來看，當初他們發展這些工具時，ProxySQL 這類的方案也還不夠成熟，大家都不會想要選這個方向...)。

先記錄下來，如果之後有遇到時可以當作是一個選項...

Google 的 Load balancer：Seesaw

前幾天因為流感而睡太多，來消化一些文章。

上個星期 Google 放出一套用 Go 寫的 Load balancer，叫 Seesaw：「Seesaw: scalable and robust load balancing」。

比較有趣的是 BGP 與 anycast VIP 的能力：

Seesaw v2 provides full support for anycast VIPs - that is, it will advertise an anycast VIP when it becomes available and will withdraw the anycast VIP if it becomes unavailable.

Google 這個規模玩的是不同 scale 的花樣...

讓 nginx 看到 5xx 回應時，去另外一台有開 debug-mode 的 server 上再跑一次

Debug 模式會比一般的模式來的慢，但可以看到更多資訊。以往的問題是 5xx 難以重製，而 NGINX 的「Capturing 5xx Errors with a Debug Server」這篇文章介紹了如何用 nginx 實作標題的功能。

如果是隨機造成的問題就沒辦法重製，但如果是 client 的狀態造成的問題，就很有可能可以抓出來... 不是解決所有問題，但可以幫助解掉以前不太好解的狀況。

ELB 預設關閉 RC4 Cipher

在 Twitter 上看到 Jeff Barr 轉貼自論壇的公告：「Announcement: Elastic Load Balancing releases security update to disable RC4」。

既有的 ELB 不受影響，不過官方還是建議把現有的 RC4 關閉。新開的 ELB 如果需要 RC4 也還是可以手洞開回來：

If you require RC4 ciphers you can re-enable them by selecting the 2014-10 SSL Security Policy or by manually configuring the SSL ciphers used by the load balancer.

Facebook 的 Autoscale 對於電力消耗的差異

在「Facebook’s New Cluster Management Software Cuts Power Consumption」這篇看到 Facebook 的 Qiang Wu 說明了他們發展的 Autoscale 技術對於電力消耗的差異：

One type of a web server Facebook uses, for example, draws 60 watts when idle, 130 watts at low-level CPU utilization and 150 watts at medium-level utilization.

利用這種差異，與傳統的 load balancing 技術比較起來，就有節省的空間了：

這是 web cluster 節省的情況，約省了 27% 的電力，這個數字以 Facebook 的規模來計算省下的電力資源超級可觀...

AWS 的 ELB 可以自訂 HTTP/HTTPS Timeout 時間了

Elastic Load Balancing 之前的 timeout 時間是預設值 60 秒，現在可以自訂時間了：「Elastic Load Balancing Connection Timeout Management」。

文章裡有提到好處：

Some applications can benefit from a longer timeout because they create a connection and leave it open for polling or extended sessions. Other applications tend to have short, non- recurring requests to AWS and the open connection will hardly ever end up being reused.

目前可以設定 1 秒到 3600 秒，預設值是 60 秒。

AWS Elastic Load Balancing 服務支援 Connection Draining

AWS Elastic Load Balancing 支援 Connection Draining 功能了：「ELB Connection Draining - Remove Instances From Service With Care」。

由於 Connection Draining 是自創名詞，所以 AWS 的人解釋了一大堆。其實對比較熟悉的人用「graceful shutdown」就應該能了解 Connection Draining 想要做什麼事情。

技術上的細節是，當 instance 從 ELB 內被移除 (無論是暫時性的還是永久性的)，新的 request 將不會被送到該 instance 裡，而既有的連線將不會斷掉，直到 client 完成或是超時 (timeout)。

這個功能在一般商用的 load balancing solution 都會提供，而且是對於服務品質其實還蠻重要的功能。

話說回來，這陣子 ELB 動了不少東西？不查資料可以直接想到的就包括了：

  • HTTPS 支援 PFS。
  • 支援 access log 下載。

再加上今天的 graceful shutdown。每次都改善一些東西，累積起來就是驚人的財產...