Home » Computer » Network » Archive by category "Service" (Page 3)

AWS 提供模擬 Amazon Aurora 異常的測試功能...

Twitter 上看到 Jeff Barr 提到了在 Amazon Aurora 上的模擬 (這邊應該是講 MySQL):

指到的頁面是文件「Managing Amazon Aurora MySQL - Amazon Relational Database Service」,翻了一下 Wayback Machine,看起來之前就有了,只是現在拿出來再宣傳一下:「Managing Amazon Aurora MySQL - Amazon Relational Database Service」。

透過主動觸發 Amazon Aurora 異常,可以測試整個系統的後續反應:

  • A crash of the master instance or an Aurora Replica
  • A failure of an Aurora Replica
  • A disk failure
  • Disk congestion

前面三種都屬於 Aurora 本身的故障測試,第四種除了有可能是 Aurora 本身的問題外,也可以測壓力過大時的情境 (i.e. 前面透過 auto scaling 撐住了,但後面的資料庫可能沒有足夠的能力支撐)。

Amazon ECS 的 Service Discovery

AWS 宣佈了 Amazon ECS 也支援 Route 53 提供的 Service Discovery 了:「Introducing Service Discovery for Amazon ECS」。

也就是說現在都整合好了... 比較一下先前需要自己包裝起來套用的方式會少不少功夫:

Previously, to ensure that services were able to discover and connect with each other, you had to configure and run your own service discovery system or connect every service to a load balancer. Now, you can enable service discovery for your containerized services with a simple selection in the ECS console, AWS CLI, or using the ECS API.

AWS 在 2016 年的時候有寫一篇「Service Discovery for Amazon ECS Using DNS」在講怎麼透過事件的觸發配合 AWS Lambda 把服務掛上去或是移除掉:

Recently, we proposed a reference architecture for ELB-based service discovery that uses Amazon CloudWatch Events and AWS Lambda to register the service in Amazon Route 53 and uses Elastic Load Balancing functionality to perform health checks and manage request routing. An ELB-based service discovery solution works well for most services, but some services do not need a load balancer.

現在看起來都可以改用 Auto Naming API 了...

Percona XtraDB Cluster 裡各種與 LOCK 相關的指令會產生的效果

在「FLUSH and LOCK Handling in Percona XtraDB Cluster」這邊看到在 Percona XtraDB Cluster 內各種不同形式的 LOCK 指令會有不同的效果。有些跟一開始用的印象已經不太一樣了...

FLUSH TABLE WITH READ LOCKFLUSH TABLE <tablename> (WITH READ LOCK|FOR EXPORT) 都會直接讓整個 node 卡住,但 LOCK TABLE <tablename> READ/WRITE 就只會卡對應的表格,另外 GET_LOCK 本來應該是完全不支援,現在似乎變成 experimental 的功能了 (參考「PXC Strict Mode」這邊),這樣一來 MogileFS 的資料庫部分就可以在上面跑了嗎?(當初就是因為這個問題而另外弄一組 DRBD + HeartbeatMySQL 起來跑 XD)

之後看一下什麼時候加進去的...

Cloudflare 用 ARM 當伺服器的進展...

Twitter 上看到 Matthew Prince (Cloudflare 的創辦人與現任 CEO) 提到了目前的進展,貼出一張兩者用電量的差距 (235W 與 150W):

兩者差了 85W,如果以五年來算就差了 3723 度的電,另外再考慮 PUE 與機櫃空間租用的成本,長期應該是頗有機會換掉原來的 x86 系統。反過來看,短期有轉換測試成本以及 (可能會有的) 較高的故障率 (畢竟是白老鼠 XD),再來是機器本身價錢差距,這些都是會想要知道的...

在 tweet 後 Matthew Prince 有回答一些問題,另外可以看到後續會有更多細節會整理出來,但感覺應該是調整的差不多決定會換過去了?這邊算是延續去年十一月「Cloudflare 測試 ARM 新的伺服器」這篇所做的事情,當時他們拿到 ARM 的工程板在測試,就已經跟 Xeon 打的差不多 (有輸有贏),現在應該又改善更多...

看 retweet 數可以看出來大家還滿期待的,畢竟 ARM 上面的 Linux 本來就因為行動裝置很熱,現在主要還是差在有沒有穩定的伺服器可以用。

一路從 MySQL 5.5 升級到 MySQL 8.0 的故事...

在「Migrating to MySQL 8.0 without breaking old application」這邊看到這個有趣的故事 XD 這是作者的應用程式 DrupalMySQL 5.5 一路升級到 8.0 的過程記錄...

真正的問題發生在 5.7 到 8.0:

原因是 Drupal 用到關鍵字了:

In fact, this old Drupal, uses a table name that is now part of the reserved keywords. It’s always advised to verify what are the new keywords reserved for MySQL itself. New features can also mean new keywords sometimes.

修正後就好了:

話說依照「File:Drupal release timeline.png」這邊的資訊,Drupal 6.2 也十年左右了?應該是 PDO 剛開始要推廣的年代,不知道他跑哪個版本的 PHP...

另外 MySQL 的升級意外的順利?雖然是一步一步升,但沒遇到什麼大問題...

Let's Encrypt 的 Wildcard Certificate 開放使用!

Twitter 上看到這則 tweet,Let's Encrypt 正式開放 Wildcard Certificate 了:

參考「ACME v2 and Wildcard Certificate Support is Live」這邊的說明,裡面有提到 Wildcard Certificate 需要有 ACMEv2 的 client:

Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv2. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

翻了一下「ACME Client Implementations」,我常用的 dehydrated 也支援 ACMEv2 了,而且剛好前幾天我更新了 PPA (參考「PPA for dehydrated : Gea-Suan Lin」),把最新版 (0.5.0 後的 6e802dd) 包進去了,等下來測試看看要怎麼玩 XDDD

然後我之後打算把 letsencrypt.tw 的資料改丟到我的 Wiki 上,這樣改起來比較簡單...

Cloudflare Workers 開放使用

Cloudflare 宣佈 Cloudflare Workers 開放使用了:「Everyone can now run JavaScript on Cloudflare with Workers」。先前的消息可以參考「Cloudflare Worker 進入 Open Beta 讓大家玩了...」與「Cloudflare 也能在各端點跑 JavaScript 了」。

價錢還直接做一張圖出來,每一百萬次 request 收費 USD$0.5,然後低消是 USD$5/month (也就是一千萬次 request):

相當於是多了一些選擇,擋在前面做些簡單的事情應該還不錯...

今年十月 Firefox 將完全不信任 Symantec 簽出的 SSL Certificate

Mozilla 旗下的產品 (包括 Firefox) 將在今年十月對 Symantec 簽出的 SSL Certificate 終止信任:「Distrust of Symantec TLS Certificates」。

Mozilla 有把發生的事情都整理出來:「CA:Symantec Issues」,另外 Firefox 的動作分成三個階段,目前 stable 是 58,但 nightly 是 60 了:

  • January 2018 (Firefox 58): Notices in the Browser Console warn about Symantec certificates issued before 2016-06-01, to encourage site owners to replace their TLS certificates.
  • May 2018 (Firefox 60): Websites will show an untrusted connection error if they use a TLS certificate issued before 2016-06-01 that chains up to a Symantec root certificate.
  • October 2018 (Firefox 63): Distrust of Symantec root certificates for website server TLS authentication.

去年 Google Chrome 就有先丟出對 Symantec CA 的計畫 (參考「Google Chrome 對 Symantec 全系列憑證的不信任計畫」這篇),看起來 Mozilla 的計畫也差不多,但時間有些差異...

DNSFilter 使用 InfluxDB 與 TimescaleDB 的過程

DNSFilter 這篇講 InfluxDBTimescaleDB 的文章頗有趣的:「Towards 3B time-series data points per day: Why DNSFilter replaced InfluxDB with TimescaleDB」。

在沒有實際用過之前,其實都只能算是一方之詞... 另外這種轉換其實也跟每個公司內的組織組成有關,像是熟悉 PostgreSQL 的單位就比較有機會用 TimescaleDB 解決 time series data 的問題。

不過有個地方倒是讓我想記錄起來:

Comparing TimescaleDB to InfluxDB at the same time — we realized we were losing data. InfluxDB relied on precisely timed execution of rollup commands to process the last X minutes of data into rollups. Combined with our series of rollups, we realized that some slow queries were causing us to lose data. The TimescaleDB data had 1–5% more entries! Also we no longer had to deal with cardinality issues, and could show our customers every last DNS request, even at a monthly rollup.

會掉資料等於是跟 InfluxDB 的使用者發出警訊,要大家確認自己手上的資料是否正確... 這對於正確性要求 100% 的應用就不是開玩笑了 @_@

Archives