.internal 被提案要列入 Reserved Top-Level Domain

意外看到「Proposed top-level domain string for private use: ".internal" (icann.org)」這篇,發現 .internal 還沒被 ICANN 列入 reserved top-level domain?原文在 ICANN 的網站上:「Proposed Top-Level Domain String for Private Use」。

這邊有兩個不同的權力組織 (團體),一邊是掌握著 root name server 規範的非營利組織 ICANN,不過 ICANN 也決定了有哪些 top-level domain 可以賣...;另外一邊是社群與 IETF 在寫下各種建議與制定標準。

現在看起來是在 RFC 6762 (Multicast DNS) 這邊講 Multicast DNS 的地方,意外的在附錄的提到了 .internal 這組 domain:

We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose:

然後列出了六個 domain:

      .intranet.
      .internal.
      .private.
      .corp.
      .home.
      .lan.

看起來也不是說這六組要被保留,比較像是講個現象?現在 .internal 要被放進去算是補一些決議?真的有公司想要申請這六組任何一個應該都不會過...

YAML 的問題 (挪威問題)

Hacker News 首頁上看到的,YAML 寫多的人都遇過類似的問題:「The Norway Problem - why StrictYAML refuses to do implicit typing and so should you」,對應的討論「The Norway Problem (hitchdev.com)」也可以看一下。

第一個「經典」是字串不需要包起來就很容易出事,這邊提到的例子是因為保留字而中槍,挪威的簡碼 NO 變成 False 了:

countries:
- GB
- IE
- FR
- DE
- NO
>>> from pyyaml import load
>>> load(the_configuration)
{'countries': ['GB', 'IE', 'FR', 'DE', False]}

同樣的是字串問題,「看起來」是數字的就會變成數字:

python: 3.5.3
postgres: 9.3

然後還是字串,人名遇到保留字:

first name: Christopher
surname: Null

這種問題都是碰過一次學一次...

作者另外提到的 StrictYAML 改變了 YAML 規格,我會看看就好,能用 JSON 也許還是會偏好先用 JSON,不是完全解決,但踩雷的機率會少很多。

把 blog 從 t4g.small 降到 t4g.micro

我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2t4g.small 上 (2GB RAM + 20% CPU credit),跑了一陣子把 CPU usage 拉出來看:

當初估大約要 20% 的 CPU credit,結果發現 CPU credit 大概用 5% 就夠了。另外記憶體的部份大約要給 1GB,這個量可以看出來一些沒在用的 process 會被丟到 swap:

              total        used        free      shared  buff/cache   available
Mem:          952Mi       380Mi        79Mi       110Mi       492Mi       368Mi
Swap:         511Mi       152Mi       359Mi

把條件綜合起來計算,就往下降一階變成 t4g.micro 了 (1GB RAM + 10% CPU credit)。

另外新機種比較不用擔心淘汰速度,就看了一下 Reserved Instances 的價錢,一年 USD$44,三年 USD$84,看起來只要有用兩年就算是 OK,直接買三年解決掉...

EC2 宣佈 Reserved Instances 降價

Amazon EC2 的 Reserved Instances 宣佈降價:「EC2 Price Reduction – For EC2 Instance Saving Plans and Standard Reserved Instances」。

文章裡先列出 M5/C5/R5 的:

可以看到 R5 在一年是完全沒動,然後有些也是 0%,不過大多數應該是都有降:

Below I’ve given a snapshot of some of the savings across the M5, C5, and R5 instance types, however there are also price reductions for the instance types C5n, C5d, M5a, M5n, M5ad, M5dn, R5a, R5n, R5d, R5ad, R5dn, T3, T3a, Z1d, and A1.

以這些資料看起來是降了一些,但實際想要翻 T3a 系列機器的歷史資料時發現不好找,用搜尋引擎可以在「Where can I find Amazon EC2 price history?」這邊看到「https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/index.csv」這個地方,看起來是「New – AWS Price List API」這邊的資訊,不過看起來沒有 RI 的資料,只有 AmazonEC2 的資料 (所以對應到的都是 $0.00)。

之後看看有沒有其他地方有留這些資訊好了...

EC2 推出 18TB 與 24TB 的機器...

AWS 又把機器給生出來啦:「EC2 High Memory Update – New 18 TB and 24 TB Instances」。

一樣是限制要買三年 RI 才能用,不過價錢頁面上好像還在更新,在「Amazon EC2 Dedicated Hosts Pricing」只看到了之前就公佈的 12TB 價錢,還沒看到 18TB 與 24TB 的部份...

然後以前會跟同事說,資料小於這台機器記憶體大小的不能叫 big data (當時是 12TB),現在升級到 24TB 啦...

EC2 開始陸續推出支援 100Gbps 網路的機器

AWS 開始陸陸續續在推出有 100Gbps 能力的 EC2 instance 了:「New – EC2 P3dn GPU Instances with 100 Gbps Networking & Local NVMe Storage for Faster Machine Learning + P3 Price Reduction」。

從「Amazon EC2 Instance Types」這邊可以看到先前只有 c5n.18xlarge 有支援 100Gbps 網路,現在推出的 p3dn.24xlarge 是第二個支援的...

另外是 P3 系列的降價消息,比較奇怪的是從 2018/12/06 開始生效,而不是從月初開始。另外區域與條件也有一些複雜,有常在用的人可以翻一下說明...

EC2 提供短期 RI 選項...

Amazon EC2 推出了短期 RI 選項:「Amazon EC2 now offers On-Demand Capacity Reservations」。

最早的 RI 設計包括了「保證一定開的起來」與「折扣」,但後來 AWS 大概是發現大家都是要「折扣」而不是保證開的起來,所以就開放了只有 discount 的部份。把原來有保證一定開的起來的部份變成 Zonal Reserved Instances。

不過 Zonal Reserved Instances 最少要一年 (有對應的折扣),這次規劃的 On-Demand Capacity Reservations 可以隨時取消,但是就沒折扣了:

Previously in order to achieve a capacity reservation, customers had to leverage Zonal Reserved Instances and commit to that capacity for a minimum of one year. Now with On-Demand Capacity Reservations, customers can reserve the exact capacity they need, in the location they need, and can keep it only for as long as they need it.

不過費用計算上會組合已經買的 Regional RI,如果沒被用掉的話還是可以將對應的折扣拿進來用:

If you have Regional RI discounts, they will automatically apply to any matching Capacity Reservation. This gives you the flexibility to selectively add capacity reservations and still get the Regional RI discounts for that usage.

算是對需要「保證開的起來」的單位提供短期的彈性,實際上後面應該是去 spot instance 那邊踢一些機器出來?XD

AWS 推出 EC2 Fleet:直接混搭標準 EC2、Spot、RI 的計算

AWS 將本來 EC2Spot Fleet 加上了 EC2 Fleet,計算的公式從本來只有 Spot Instace,變成把標準 EC2 Instance 與 RI 的計算全部都納進來:「EC2 Fleet – Manage Thousands of On-Demand and Spot Instances with One Request」。

Today we are extending and generalizing the set-it-and-forget-it model that we pioneered in Spot Fleet with EC2 Fleet, a new building block that gives you the ability to create fleets that are composed of a combination of EC2 On-Demand, Reserved, and Spot Instances with a single API call.

不過目前有些服務還沒整,主要是跟 auto scaling 有關的部份,這部份應該是一次上一大包:

We plan to connect EC2 Fleet and EC2 Auto Scaling groups. This will let you create a single fleet that mixed instance types and Spot, Reserved and On-Demand, while also taking advantage of EC2 Auto Scaling features such as health checks and lifecycle hooks. This integration will also bring EC2 Fleet functionality to services such as Amazon ECS, Amazon EKS, and AWS Batch that build on and make use of EC2 Auto Scaling for fleet management.

整完以後對於要省成本就更簡單了...

一路從 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 的升級意外的順利?雖然是一步一步升,但沒遇到什麼大問題...

AWS 讓你可以禁止 RI 跨帳號計算了...

現在 AWS 讓你可以設定,是否允許 Reserved Instance (RI) 跨帳號使用:「Customize your organization’s AWS credit and Reserved Instance (RI) discount sharing using new billing preferences」。

以往是優先用在自己帳號,但如果有剩的話可以挪去其他帳號用。這樣雖然比較省錢,但有時候會造成帳務的「困擾」:

Historically, AWS has maximized customer savings by applying credits and RI discounts first to the account that owned the credit or RI lease and then distributing the remainder, if any, to qualifying usage incurred by accounts in the same organization. While this approach had the potential of lowering the overall bill, customers were unable to control if, and how, discounts were applied across organizational lines.

現在則是可以關掉:

To provide greater flexibility, customers can now disable AWS credit sharing across all accounts in their organization. This ensures that only the account that owns a credit, or has previously redeemed a credit, receives the associated benefit.

也可以分開設定:

You can also designate a set of accounts for which RI discount sharing is disabled, while continuing to share RI discounts among the rest of the accounts in your organization.

這樣雖然會比較貴,但這其實反應到某些組織文化上的問題啦...