Tag: vm

跑 ArchiveTeam Warrior

Archive Team 是一個致力於保存數位資料的組織，而 ArchiveTeam Warrior 則是他們提供的軟體，可以讓你很方便直接跑 worker 加入他們的 cluster，幫忙抓資料並且保存到 Internet Archive 上。

他們提供三種方法跑 ArchiveTeam Warrior，第一種是 VM 的方式，文件裡面有介紹怎麼用 VirtualBox 或是 VMware Player 跑起來。

第二種與第三種都是 container 類的方式，Docker 與 Podman 都能跑起來。

跑起來後可以連進 http://127.0.0.1:8001/，然後選擇想要加入的項目，或是接受指令選擇目前團隊主打的項目。

在「Projects」這頁可以看到目前主力是備份 Enjin 上的資料。

丟了兩台 VPS 的機器上去用 Docker 跑，CPU 使用率看起來很低，但網路流量看起來會因為所在的地點而差蠻多的，一台大約是 300KB/sec 到 400KB/sec，換算後大約是 1TB/mo，另外一台則只有 1/10 的量。

Netflix 單機 800Gbps 伺服器所使用的最佳化技巧

在 Hacker News 上看到 Netflix 的人丟出來的投影片，試著了解 Netflix 的 Open Connect Appliances 裡與 FreeBSD 相關的最佳化技巧對於效能的影響：「The “other” FreeBSD optimizations used by Netflix to serve video at 800Gb/s from a single server」。

看起來這邊的分析是先基於 400Gbps 的版本，可以跑到 375Gbps (53% CPU)，接著在上面拔掉各種最佳化的設定，看看會掉多少流量。這邊可以參考先前在「Netflix 在單機服務 400Gbps 的影音流量」提到的資料。

投影片上的第一章是 sendfile 與 kTLS 相關的最佳化，這邊可以看出來都是重要的項目，隨便關掉一個就會掉很多 capacity：

  • Disable kTLS (and async sendfile) + nginx aio：40Gbps (100% CPU)
  • Disable kTLS (and async sendfile) + nginx thread pools：90Gbps (90% CPU)
  • Disable sendfile (but use kTLS)：75Gbps (80% CPU)
  • Disable sendfile (but use NIC kTLS)：95Gbps (80% CPU)
  • Enable Sendfile & kTLS, but disable ISA-L crypto：180Gbps (80% CPU)
  • Enable Sendfile & kTLS：240Gbps (80% CPU)

第二章是 virtual memory，UMA VM Page Cache 這邊看起來最明顯，SF_NOCACHE 也是個重要的項目：

  • Disable UMA VM Page Cache：60Gbps (95% CPU)
  • Disable VM Batch Queues：280Gbps (95% CPU)
  • Disable SF_NOCACHE：120Gbps (55% CPU)

另外第二章特別提到了一個之前沒有用到的 optimization，是把 arm64 上面的 4KB Pages 變成 16KB Pages，這帶動了些許的效能提昇，並且降低了 CPU 使用率：

345Gb/s @ 80% CPU -> 368Gb/s @ 66% CPU

第三章是 network stack，看起來 TSO 帶來的效益也是很高：

  • Disable TCP Large Receive Offload：330Gbps (65% CPU)
  • Disable RSS accelerated LRO：365Gbps (70% CPU)
  • TSO Disabled：180Gbps (85% CPU)
  • Disable TSO and LRO：170Gbps (85% CPU)

最後面則是有提到從 400Gbps 到 800Gbps 還多做了那些事情，最後是達到 731Gbps。

用的機器是 Dell PowerEdge R7525，這是一台 2U 的機器啊...

VirtualBox 7.0.0 出了

在 LWN 看到 VirtualBox 7.0.0 出了：「VirtualBox 7.0.0 released」，其中 Changelog 可以在「Changelog-7.0」這邊翻到。

Ubuntu 下的更新還算方便，先把 VM 都關掉，移除 virtualbox-6.1 後再裝 virtualbox-7.0，然後把 VM 開起來看看有沒有什麼問題。

在 Changelog 裡面看到這個，這些 3D support 不知道有支援到什麼程度：

Devices: Implemented new 3D support based on DirectX 11 (and DXVK on non Windows hosts)

我把 Enable 3D Acceleration 的選項打開後變成只能跑 1600x1200，本來 1920x1200 不能跑，所以只好又關掉...

另外是支援了 virtual TPM 可以掛進去：

Devices: Added virtual TPM 1.2 and 2.0 devices

然後以前 USB 裝置的支援是 proprietary software，現在放到 open source 版本裡面了：

Devices: The EHCI and XHCI USB controller devices are now part of the open source base package

目前用起來沒什麼大問題，繼續觀察看看。

現在的 vm.swappiness

查了一下現在的 vm.swappiness，發現跟以前又有一些差異。在「Documentation for /proc/sys/vm/」這邊可以看到說明。

很久以前應該是 0 到 100，現在變成 0 到 200 了，其中設定成 100 會在比重公式裡讓 memory 與 swap 的計算上有相同的比重：

This control is used to define the rough relative IO cost of swapping and filesystem paging, as a value between 0 and 200. At 100, the VM assumes equal IO cost and will thus apply memory pressure to the page cache and swap-backed pages equally; lower values signify more expensive swap IO, higher values indicates cheaper.

另外是設定 0 時的方式，在不夠用的時候還是會去用：

At 0, the kernel will not initiate swap until the amount of free and file-backed pages is less than the high watermark in a zone.

目前看起來之前建議設成 1 的方式應該是還 OK...

Travis CI 支援 Arm64 平台的編譯與測試了

剛剛看到 Travis CI 宣佈支援 Arm64 的編譯與測試環境了：「Announcing General Availability of Graviton2 CPU Support!」。

架構上是利用 AWS 推出的機器來做，其中支援的 OS image 目前看起來是以 Ubuntu 為主，其中 16.04 (xenial) 與 18.04 (bionic) 只有 LXD container 的環境，而 20.04 (focal) 則除了 LXD container 環境外，也有完整的 VM 環境可以跑：

Following Arm64 distributions of Ubuntu are available for you as LXD containers:

Xenial (16.04)
Bionic (18.04)
Focal (20.04)

Following Arm64 distribution of Ubuntu is available for you as a full VM option:

Focal (20.04)

看起來底層是用 Ubuntu 20.04 為主力，然後提供 container 跑其他版本。

VirtualBox 裡面跑 OS/2 的指引

在「OS/2 on Virtualbox guide」這邊看到在 VirtualBox 上裝 OS/2 的指引，引用的文章在「OS/2 on Virtualbox Guide」這邊。

讓人懷古的東西...

另外文章的作者有提到，有試著在實體機器與其他的 VM 環境裝 (這邊提到了 QEMU)，不過結果不太行：

Note: On real hardware, or on other VM platforms, I have found OS/2 to be extremely fragile. When I installed it on my real P1 and P3 Dell machines, I had to reboot multiple times during the setup and driver install processes due to hangs, and I had a ton of issues with random errors on boot.

I also tried all this on QEMU 4.2.0 and had very similar problems, and I had developed some very negative opinions about OS/2's reliability before I switched to Virtualbox and found that it was actually quite solid and the installs went very smoothly.

主要還是有趣吧...

OpenVZ 裡的 Docker

前幾天在公司弄 GitLab 與 GitLab CI，前者光跑起來都還沒動他就先吃 1.5GB 左右的記憶體，動兩下就 2.5GB 了。後者的 CI 隨著使用的情況而改變，不過最少丟個 1GB 差不多...

公司用的機器當然是還好，先簡單弄一台 t3a.medium (4GB) 跑 GitLab 主體，然後另外一台 t3a.small (2GB) 跑 CI 的 Runner，真的有需要的時候可以再往上拉...

不過自己也要弄的時候就會考慮到成本問題，畢竟也只有自己一個人用，如果在 Vultr 上面租類似的機器就要 USD$30/month，其他的 KVM VPS 也都差不多價錢。

而 OpenVZ 的 VPS 主機一向都比 KVM 的 VPS 便宜不少，但有不少限制。其中一個限制就是沒辦法跑 Docker，這樣就沒辦法把 GitLab CI 的 Runner 跑上去了 (有其他模式可以跑，但我這邊偏好用 Docker)。

查了一下資料 (因為記得 OpenVZ 有計畫要支援 Docker)，發現 OpenVZ 7 已經支援 Docker 了，而且在官方文件上面也都已經有說明了：「10.3. Setting Up Docker in Virtuozzo Containers」、「Docker inside CT vz7」。

然後順著找一下，發現市場上也已經有 OpenVZ 7 的 VPS，而且會宣傳支援 Docker，試著租一個月也確認可以跑，這樣代表之後又有更多選項啦...

GCE 的 IP 要收費了...

收到信件通知，本來在 GCE 上使用的 Public IP address 是免費的，2020 年開始變成要收 USD$0.004/hr (Standard，約 USD$2.88/month) 或是 USD$0.002/hr (Preemptible，約 USD$1.44/month)：

First, we’re increasing the price for Google Compute Engine (GCE) VMs that use external IP addresses. Beginning January 1, 2020, a standard GCE instance using an external IP address will cost an additional $0.004/hr and a preemptible GCE instance using an external IP address will cost an additional $0.002/hr.

從 2020 年一月開始生效，但是前三個月會用 100% discount 的方式呈現在帳單上 (所以還是免費)，這樣你會知道你的 IP address 費用會吃多少錢：

We will fully discount any external IP usage for the first 3 months to help you quantify the impact of these pricing changes. Please take note of the following dates:

January 1, 2020: Although your invoice will show your calculated external IP-related charges, these will be fully discounted and you will not need to pay these.
April 1, 2020: You will need to pay for any incurred external IP-related charges shown on your invoice.

其實整體成本應該是還好，但看到漲價總是不開心... XD

把 Docker Image 轉成 VM Image

看到「ottomatica/slim」這個專案：

slim will build a micro-vm from a Dockerfile. Slim works by building and extracting a rootfs from a Dockerfile, and then merging that filesystem with a small minimal kernel that runs in RAM.

This results in a real VM that can boot instantly, while using very limited resources. If done properly, slim can allow you to design and build immutable unikernels for running services, or build tiny and embedded development environments.

從 screenshot 可以看到會產生 ISO Image：

產生的 ISO Image 可以透過 HyperKit (在 macOS 時) 或是 VirtualBox 跑起來。

實際用途不知道多大，算是一種嘗試？

Kubernetes 的失敗案例

有人把 Kubernetes (通常縮寫成「K8S」) 的失敗案例 (轉移失敗、爛掉、...) 整理到 GitHub 上：「Kubernetes Failure Stories」，裡面有文章也有演講影片，然後也有重複的公司在不同時間點說明。

先來講 K8S 好了，如果要粗略的解釋 K8S 是什麼東西，我會說就像是架一組 AWS 服務起來，但是是基於 container 而非 VM。

拿 AWS 的詞彙來說，他在上面疊了一層 Amazon VPC (會對應到 Kubernetes 的 overlay network 與 CNI)，然後也提供 AMI (透過 Docker Image) 與 EC2 (因為是比喻，這邊就拿 AMI + EC2 來對比)，還有基本的 ELB (各種 NodePort、HostPort 與 Ingress) 與 Service Discovery。

比較特別的是 Pod 的概念，在一般的雲上不太會看到。

不過大致上你可以想像這是一個小型的 AWS，而試著去猜測管理一個小型的 AWS 會需要了解多少底層知識，加上 K8S 一直在發展，很多功能可能都還不成熟 (所以用起來會覺得設計很奇怪)，然後上面整理出的失敗案例就不意外了... XD

如果你是自己有機房，或是用便宜的 VPS (像是 Linode、DigitalOcean、Vultr)，那麼我覺得在上面堆 K8S cluster 還算合理，畢竟你可以透過 K8S 幫你整合不少以前得自己架設的服務。

但如果你是已經在 Cloud 上面，然後還想在上面跑 K8S cluster，我是覺得還是要有個理由 (不管是技術上或是政治上的)。如果只是因為 K8S 潮到出水而用的話，可能過一個月後你家就淹水了 XD

另外講一些題外話，因為最近弄 Kubernetes 的關係 (可以參考我的筆記「Kubernetes」)，才能理解為什麼 Linode 這些 VPS 會推出 load balancer 與 block storage，算是後知後覺...