Tag: direct

AWS Direct Connect 開始提供 400Gbps 的選擇

AWS Direct Connect 開始有 400Gbps 的選擇了：「AWS Direct Connect announces native 400 Gbps Dedicated Connections at select locations」。

依照裡面的 AWS Direct Connect Locations 連結可以知道目前開放的地點都在北美：

  • CoreSite VA1, Reston, VA
  • Equinix DC2/DC11, Ashburn, VA
  • CoreSite SV4, Santa Clara, CA
  • Equinix SV5, San Jose, CA

Terabit Ethernet 這邊翻400Gbps 的部分，是 2017 年的標準，另外有些比較長距離的選擇是後續推出來的。

這樣算是給了一些需要穩定大流量的企業的選擇，不然 internet 集縮比的問題造成線路頻寬時高時低。

話說 Direct Connect 在台灣的兩個點目前都還是掛到東京區 (ap-northeast-1) 上，後續台北 region 開點後不知道是會支援多個 region (i.e. 可以掛東京，也可以掛台北)，還是會另外找機房接？

AWS 印尼雅加達區開放使用

AWS 宣布印尼雅加達區開放使用，代碼 ap-southeast-3：「Now Open – AWS Asia Pacific (Jakarta) Region」。

要注意雅加達區需要另外 enable 才能用：

As is the case with all of the newer AWS Regions, you need to explicitly enable this one in order to be able to create and manage resources within it.

另外也同時宣布了雅加達的 AWS Direct Connect 接點：「AWS Direct Connect announces two new locations in Indonesia」。

公司主力目前用新加坡 (ap-southeast-1)，好像有不少事情得做... (至少要先規劃)

OpenBGPD 接 AWS Direct Connect 時只讓單區路由的方法

算是繼上篇「用 pfSense 接 AWS Direct Connect (Public VIF) 的方式」的改善，上篇的方法設定完後預設會是全部都會 routing 進來。也就是說，如果你接到新加坡區，美東 routing 也會進來。

這可能是你要的，但也可能不是你要的，所以找了一下方法，在 AWS 的文件裡面有提到可以透過 BGP community 控制這些 routing：「Routing policies and BGP communities」。

第一個方向是從 pfSense 送出去的封包，這個要過濾從 BGP 送進來的 routing table：

AWS Direct Connect applies the following BGP communities to its advertised routes[.]

把：

allow from 1.2.3.4

改成：

allow from 1.2.3.4 community 7224:8100

另外一個是讓 AWS 不要把我們的 network 送到其他區，這是在 network 上加上 BGP community tag：

You can apply BGP community tags on the public prefixes that you advertise to Amazon to indicate how far to propagate your prefixes in the Amazon network, for the local AWS Region only, all Regions within a continent, or all public Regions.

把本來的：

network 1.2.3.4/30

變成：

network 1.2.3.4/30 set community 7224:9100

先這樣搞，用 mtr 看了一下應該沒錯...

用 pfSense 接 AWS Direct Connect (Public VIF) 的方式

公司在菲律賓的辦公室因為常常會需要連到 AWS 傳輸影音資料 (新加坡，ap-southeast-1)，但發現偶而會很不順，傳輸的時候會很卡，所以後來決定租了一條專線用 AWS Direct Connect 接進去。

不過因為跑在 AWS 上面的服務是掛在 public network 上，而不是 private ip 的網段，所以就不能用 IPsec site-to-site 打通收工，而需要搞 BGP routing，然後就卡關卡的亂七八糟 XD

首先是文書作業的部份，因為 AWS 對於 public network peering 需要證明你要交換的 IP address 是你自己的 (或是有被授權)，這部份在 web console 上建立完 Public VIF 後會進入審核階段，接下來就要開 support ticket 提供 LOA-CFA 文件後才能繼續設定，我們這邊是從 ISP 申請 AWS Direct Connect 線路時拿到這份 PDF 文件。

這邊比較有趣的是，如果你沒有買 support plan 的話無法開 technical support，但官方有跟你說這邊可以 workaround 開 General Info and Getting Started 這個類別：「My public virtual interface is stuck in the "Verifying" state. How can I get it approved?」。

過了審核後接下來是設定 pfSense 的部份，因為是要接通 public network 的部份，所以你要收 AWS 提供的 BGP routing，這部份在 pfSense 上會透過 OpenBGPD 解決，但主要還是因為對 BGP 不熟悉，所以花了不少時間跟 AWS 原廠與台灣的 Partner 一起找問題，不然現在事後來看，自己 tcpdump 應該就有能力找到問題了...

主要的盲點是在我們的 AWS Direct Connect 裡面 BGP 需要走 TCP MD5 Signature Option。

這是一個 TCP extension，連線雙方有一把 shared secret 可以驗證每個 TCP packet 沒有被竄改：「Protection of BGP Sessions via the TCP MD5 Signature Option」。

要注意的是這個協定不是 application level，而是在 TCP 層本身就保護起來，包括 3-way handshake 的部份，所以從一開始 SYN 封包過去就要有 md5sig 的資訊。

這也表示用 telnet 不會通是正常的，這點讓我找問題找錯方向好久...

另外一點是 pfSense 的預設值不支援 TCP MD5 Signature Option (完全沒想過這個可能性 XDDD)，這點在 pfSense 的「md5 bgp sessions fail in 2.4.0」這邊有提到：

Do you have "BSD Crypto Device" selected under System > Advanced, Misc tab, for Cryptographic Hardware? If not, select it there and try again.

That module is required for TCP_SIGNATURE to function.

If that works I can either add some warning text to Quagga and FRR or force it to load when that is enabled.

到了對應的選項那邊要選擇，因為我們的 pfSense 機器比較低階，沒有那堆硬體加速度的東西，所以選「BSD Crypto Device (cryptodev)」讓底層的 FreeBSD 去處理。

設定完後新的連線也還是不會有效果，後來想了一下還是整台重開機，然後就通了就通了就通了就通了就通了...

果然弄很久的問題都會是蠢問題，純粹就是不熟悉這些東西造成的。

AWS Direct Connect 在台北又增加可以接的機房了...

先前 AWS Direct Connect 在今年二月的時候公佈了台北第一個開放的接點，是方的麗源機房 (Chief Telecom LY, Taipei, Taiwan，參考「AWS 公開了在台北的 Direct Connect 接口」)，現在公佈第二個點了：「New AWS Direct Connect locations in Paris and Taipei」。

第二個點在中華電信的機房 (Chunghwa Telecom, Taipei, Taiwan)，但這樣只這樣標，不知道實際上是哪個，會不會是愛國東路的國分機房？那邊有不少非中華電信網路的客戶，只是租那邊的機房在用...

不過有需求的可以問一下 AWS，應該就會有答案了，畢竟總是得讓客戶知道要接到哪邊...

AWS 公開了在台北的 Direct Connect 接口

也是個很久前就聽到傳言的消息... AWS 剛剛公佈了在台北的 Direct Connect 接口，用戶可以在台北內租用線路進機房就連上 Direct Connect：「New AWS Direct Connect sites land in Paris and Taipei」。

AWS Direct Connect also launched its first site in Taiwan at Chief Telecom LY, Taipei. In the Management Console, Taipei is located in the Asia Pacific (Tokyo) Region. With global access enabled for AWS Direct Connect, these sites can reach AWS resources in any global AWS region using global public VIFs and Direct Connect Gateway.

以往需要透過像 GCX 這樣的公司租用國際頻寬，再從 GCX 在台北的機房拉到自家機房 (通常是市內專線)，現在只需要在台北對接的這段就可以了。

台北的接點在 AWS 上寫的是 Chief Telecom LY, Taipei, Taiwan，查了一下是是方電訊的「是方麗源大樓 (台北市內湖區陽光街250號)」，也就是之前有發生過火災而大斷線的那棟。對接的 AWS Home Region 是 Asia Pacific (Tokyo)，所以使用 ap-northeast-1 的人可以規劃...

Amazon Device Farm 支援讓使用者直接連上去 debug 了...

Amazon Device Farm 推出這樣的功能又朝著設備租賃服務更進一步了：「Amazon Device Farm Launches Direct Device Access for Private Devices」。

Now, with direct device access, mobile applications developers can use individual devices in their private test set as if they were directly connected to their local machine via USB. Developers can now test against a wide array of devices just like they would as if the devices were sitting on their desk.

這樣就可以使用更底層的東西了...

AWS Direct Connect 可以多條線路綁在一起用了

AWS Direct Connect 支援 Link Aggregation Group (LAG)，將多條線路綁在一起了：「AWS Direct Connect enables Link Aggregation Group for additional AWS regions」。

We are excited to announce support for 1G and 10G Link Aggregation Groups (LAG). Customers in AWS GovCloud (US), Europe (Frankfurt), Europe (London), Europe (Ireland), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney) regions can start using LAG to link existing connections on the same AWS device, or request new connections.

主要還是對於超大量的用戶會變方便 (都是使用 10Gbps 線路接上去的使用者)，尤其是 load balancing 這塊會好做不少。

多條 1Gbps 的當然也是有幫助，不過剛好只會落在一個微妙的範圍 (到 8Gbps 的時候，直接換 10Gbps 成本說不定其實差不多...)。

PostgreSQL 上，直接將 SSD 的內容送到 GPU 上，加速讀取速度

在 PostgreSQL 上針對讀取檔案到 GPU 上的成果：「GpuScan + SSD-to-GPU Direct DMA」(日文版)、「(EN) GpuScan + SSD-to-GPU Direct DMA」(英文版)。

主要的原因在於雖然已經有 PGStorm 讓 PostgreSQL 把運算丟到 GPU 上加速，但從 disk 讀到 GPU 這段還是有改善的空間：

PG-Strom that is an extension of PostgreSQL to off-load multiple SQL workloads on GPU devices, transparently. It has been developed for four years, and now supports simple scan, tables join, aggregation and projection.
Its prime focus is CPU intensive workloads, on the other hands, it didn't touch storage subsystem of PostgreSQL because the earlier version of PG-Strom assumes all the data set shall be pre-loaded onto physical memory. No need to say, we had a problem when we want to process a data-set larger than physical RAM.

這是成果，可以看到速度快了一倍以上：

這對資料量超過 RAM 大小時的處理會非常有幫助 (因為會有大量的 disk i/o 發生)。

AWS 北京也支援 Direct Connect 了...

看到 AWS 官方的公告：「Announcing AWS Direct Connect for the China (Beijing) Region」。

這代表可以拉線路進 AWS 在北京的機房直連，另外可以參考「APN Partners Supporting AWS Direct Connect」的表格，可以知道要找哪些人，目前北京區看起來只有 Sinnet。