Tag: transfer

AWS 推出 Global Accelerator，用 AWS 的網路加速

AWS 推出了 Global Accelerator，利用 AWS 的網路加速：「New – AWS Global Accelerator for Availability and Performance」。

這個產品有點像是 GCP 的 Premium Network 的概念，從名稱叫做 Data Transfer-Premium (DT-Premium) 也可以看出來這點。另外 Cloudflare 也有類似的產品，叫做 Spectrum。

使用者的連線會先進入最接近使用者的 AWS Edge，然後走 AWS 自己的網路到真正服務所在的 AWS 區域：

AWS 自家的 CloudFront 可以做類似的事情，但是 CloudFront 是 DNS-based service，而且只吃 HTTP 類的連線；這次推出的 Global Accelerator 則是 Anycast-based service，同時支援 TCP 與 UDP。

目前的 edge 只有北美、歐洲與亞洲：

AWS Global Accelerator is available in US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo) and Asia Pacific (Singapore).

這類服務通常也都可以擋下一些 DDoS 攻擊，畢竟是拿大水管在擋...

AWS 日本區 EC2 與 S3 的傳輸費用降價...

在 Twitter 看到 Jeff Barr 提到日本區的 EC2 與 S3 傳輸費用降價：

網站的說明文章則是在「AWS Data Transfer Price Reductions – Up to 34% (Japan) and 28% (Australia)」這邊。分成幾個部份降價：

  • 10TB 以下的費用從 USD$0.14/GB 變成 $0.114/GB (約 19%)。
  • 10TB 到 50TB 從 USD$0.135/GB 變成 USD$0.089/GB (約 34%)。
  • 50TB 到 150TB 則是 USD$0.13/GB 變成 USD$0.086/GB (約 34%)。
  • 超過 150TB 的部份從 USD$0.12/GB 變成 USD$0.084/GB (約 30%)。

然後自動回朔到 2018/09/01 開始算：

Effective September 1, 2018 we are reducing prices for data transfer from Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3), and Amazon CloudFront by up to 34% in Japan and 28% in Australia.

另外有提到 CloudFront 也有降價，以及澳洲的部份，應該不太會碰到所以就跳過去...

但就文章這樣寫明 EC2 與 S3 的流量有降價，應該表示從 ELB 出去的流量就不算在這次的降價？除非你是直接 S3 裸奔，不然對大多數的人應該沒差？

台固的網域名稱轉出到 Gandi，以及 GDPR...

看到 othree 的「TFN 域名轉出」這篇，剛好前陣子把 git.tw 也轉到 Gandi 上，也遇到一樣的問題... 以往的經驗是網域註冊商會提供 authorization code，但台固的系統是讓你自己輸入，懂這點後就好處理了：

所以結論是，TFN 域名轉出時要輸入的移轉中密碼其實就是給使用者自訂 authorization code，而且還有個蠻短的長度限制 XD

另外是因為 GDPR 所以看不到 whois 資料了，像是 othree 提到的 markdown.tw：

gslin@GSLIN-HOME [~] [14:32/W2] whois markdown.tw
Domain Name: markdown.tw
   Domain Status: clientTransferProhibited
   Registrant:
      
      Not displayed due to GDPR
      FR

   Administrative Contact:
      Not displayed due to GDPR

   Technical Contact:
      Not displayed due to GDPR

   Record expires on 2020-03-07 (YYYY-MM-DD)
   Record created on 2011-03-07 (YYYY-MM-DD)

   Domain servers in listed order:
      ns-171-a.gandi.net      
      ns-114-b.gandi.net      
      ns-144-c.gandi.net      

Registration Service Provider: GANDI SAS

我自己的 git.tw 也是：

gslin@GSLIN-HOME [~] [14:34/W2] whois git.tw
Domain Name: git.tw
   Domain Status: clientTransferProhibited
   Registrant:
      
      Not displayed due to GDPR
      FR

   Administrative Contact:
      Not displayed due to GDPR

   Technical Contact:
      Not displayed due to GDPR

   Record expires on 2019-05-23 (YYYY-MM-DD)
   Record created on 2008-05-23 (YYYY-MM-DD)

   Domain servers in listed order:
      kristin.ns.cloudflare.com      
      paul.ns.cloudflare.com         

Registration Service Provider: GANDI SAS

這樣就有點麻煩了，以後如果要聯絡的話只剩下 DNS 內的 SOA record？

掃網域下主機名稱的方式...

原文是講滲透測試的前置作業，需要將某個特定 domain 下的主機名稱掃出來：「A penetration tester’s guide to sub-domain enumeration」。

最直接的還是 DNS zone transfer (AXFR)，如果管理者沒設好 DNS server 的話，這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。

看了一下有幾種方式：

應該有人可以提到所有的東西再寫成程式 XD

查看 Percona XtraDB Cluster 在 IST 時的進度

Percona 的「Tracking IST Progress in Percona XtraDB Cluster」這篇介紹了 PXC 在 IST 時的進度。

是個新功能，很簡單的可以看到目前進度，也可以拿來當作 health check 的一部分，避免開機剛起來時開始提供服務：

mysql> show status like 'wsrep_ist_receive_status';
+--------------------------+--------------------------------------------------------+
| Variable_name | Value |
+--------------------------+--------------------------------------------------------+
| wsrep_ist_receive_status | 3% complete, received seqno 1421771 of 1415410-1589676 |
+--------------------------+--------------------------------------------------------+
1 row in set (0.00 sec)
....
mysql> show status like 'wsrep_ist_receive_status';
+--------------------------+---------------------------------------------------------+
| Variable_name | Value |
+--------------------------+---------------------------------------------------------+
| wsrep_ist_receive_status | 52% complete, received seqno 1506799 of 1415410-1589676 |
+--------------------------+---------------------------------------------------------+
1 row in set (0.00 sec)
....
mysql> show status like 'wsrep_ist_receive_status';
+--------------------------+---------------------------------------------------------+
| Variable_name | Value |
+--------------------------+---------------------------------------------------------+
| wsrep_ist_receive_status | 97% complete, received seqno 1585923 of 1415410-1589676 |
+--------------------------+---------------------------------------------------------+
1 row in set (0.00 sec)
mysql> show status like 'wsrep_ist_receive_status';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| wsrep_ist_receive_status | |
+--------------------------+-------+
1 row in set (0.00 sec)

CloudFront 支援 IPv6

Amazon CloudFront 宣佈支援 IPv6 了：「IPv6 Support Update – CloudFront, WAF, and S3 Transfer Acceleration」。

不只是 Amazon CloudFront 支援了 IPv6，還包括了使用 CloudFront 而建出的 AWS WAF 與 Amazon S3 Transfer Acceleration。

所以對外的部份都有 IPv6 了 (包括了 ELB)，現在不支援的應該是內部機器與 Elastic IP address？

Amazon S3 推出加速功能

Amazon S3 推出了新的加速功能，並且向更多地區提供 AWS Import/Export Snowball 服務：「AWS Storage Update – Amazon S3 Transfer Acceleration + Larger Snowballs in More Regions」。

其中的 Amazon S3 Transfer Acceleration 只要把本來的 BUCKET_NAME.s3.amazonaws.com 或是帶有地區的 BUCKET_NAME.s3-region.amazonaws.com 變成 BUCKET_NAME.s3-accelerate.amazonaws.com 就可以了，他會透過 CloudFront 的節點做 proxy，並且透過 AWS 內部最佳化過的網路傳輸。

由於這是定位為 Amazon S3 的服務，而實際測試後也確認不會有 cache：他的目的在於降低 latency 而加速，而不是 cache 加速，所以大量 GET 相同內容的部份應該還是用 CloudFront 會比較好。

再來是費用的部份增加相當多，第一筆要收的是 CloudFront 的費用，再來才是計算 Transfer Acceleration 的費用：

Transfer Acceleration pricing is in addition to Data Transfer pricing.

從 Internet 進 CloudFront 再進 Amazon S3 的要收 USD$0.04/GB (透過在美國、歐洲或是日本的 CloudFront 節點) 或 USD$0.08/GB (透過其他 CloudFront 節點)。

另外要收的是從 Amazon S3 一路傳到 Internet 的部份，USD$0.04/GB。如果是傳到其他 AWS region 的話，也是 USD$0.04/GB。

不過他有效能保證條款 (雖然掌控全不在自己)，AWS 會持續監控有沒有比較快，如果沒有的話系統會 bypass 回原來的 Amazon S3：

Each time you use Transfer Acceleration to upload an object, we will check whether Transfer Acceleration is likely to be faster than a regular Amazon S3 transfer. If we determine that Transfer Acceleration is not likely to be faster than a regular Amazon S3 transfer of the same object to the same destination AWS region, we will not charge for that use of Transfer Acceleration for that transfer, and may bypass the Transfer Acceleration system for that upload.

我本來以為會是在 DNS 層 bypass 回本來的 region，結果發現是 307 redirect 重導回 Amazon S3 上，效能上應該還是會差一些...

可以看出這個架構的特性主要還是用在上傳的部份，而且用在網路不穩定的環境下很重要 (像是電信網路上的行動裝置)，因為 latency 的減少會對於 packet loss 造成的 retry 有很大的幫助。

下載的部份應該會比本來 Amazon S3 快 (因為 Amazon 本身會加速)，但由於沒有 cache，除非有特殊需求，不然建議不要這樣規劃。

另外一個是 AWS Import/Export Snowball 推出的新硬體，以及新區域。

新硬體是 80TB 的版本，本來只有 50TB 的版本：

The original Snowball appliances had a capacity of 50 terabytes. Today we are launching a newer appliance with 80 terabytes of capacity.

而新區域包括了 AWS GovCloud (US)、US West (Northern California)、Europe (Ireland) 以及 Asia Pacific (Sydney) 這三區：

Today we are making Snowball available in four new Regions: AWS GovCloud (US), US West (Northern California), Europe (Ireland), and Asia Pacific (Sydney). We expect to make Snowball available in the remaining AWS Regions in the coming year.

其中 80TB 版本只在這三區生效，其他區可以選擇 50TB 或是 80TB 版本：

If you are transferring data in or out of the US East (Northern Virginia), US West (Oregon), US West (Northern California), or AWS GovCloud (US) Regions using Snowball you can choose the desired capacity. If you are transferring data in or out of the Europe (Ireland) or Asia Pacific (Sydney) Regions, you will use the 80 terabyte appliance.

日本還是沒進場...

把塗鴉透過深度類神經網路轉成油畫...

看到「Neural Doodle」這個專案，可以把塗鴉轉成帶有油畫筆觸的圖：

看起來是實作新的演算法：

Use a deep neural network to borrow the skills of real artists and turn your two-bit doodles into masterpieces! This project is an implementation of Semantic Style Transfer (Champandard, 2016), based on the Neural Patches algorithm (Li, 2016).

另外一組範例：

程式可以用純 CPU 跑，也可以用 GPU 跑，不管哪種都很吃記憶體 XDDD

Galera Cluster (Percona XtraDB Cluster) 同步速度的改善

Percona 的「State Snapshot Transfer (SST) at a glance」這篇給了 Galera Cluster (也就是 Percona XtraDB Cluster) 在同步速度的改善方案，整篇文章一步一步改善，從 51 分鐘降到 18 分鐘。

劃幾個重點。

首先是同步時的設定可以放到系統 my.cnf 的 [sst] 內，像是這樣：

[sst]
inno-apply-opts="--use-memory=20G"

其中改善最大的也就是 --use-memory，依照作者測試的數據，光這步就從 51 分鐘降到 30 分鐘。不過這邊要小心本來就有跑的 mysqld，如果 OOM 就慘了...

再來講的是 wsrep_slave_threads，不同於上面的 sst only 設定，這是在一般性的 tuning (平常在跑的參數，放在 [mysqld] 內)，改完後速度 30 分鐘再提升到 25:32。

然後是壓縮的方式改用支援多 CPU 的 pigz：

[sst]
inno-apply-opts="--use-memory=20G"
compressor="pigz"
decompressor="pigz -d"

很明顯是個 shell command 類的設定，所以如果真的想要測的話，可以再從 -1 測到 -9，作者在這邊沒測，不過效果也很明顯了，從 25:32 降到 21 分鐘。

最後一個大的改變是建議有專門同步的節點 (Donor node)，這個節點上不會有 SQL query 來影響效能，這樣可以讓 pigz 的效率更高：

Since node2 is not getting application traffic, moving into the Donor state and doing an expensive SST with pigz compression should be relatively safe for the rest of the cluster (in this case, node1).

時間最後降到 18:33。