最近在工作上因為某些緣由看了很多關於 OpenStack nova 的 code，因而打算來寫一些文章記錄一下 nova 是如何運作的。首先第一篇將由 nova-scheduler 的部分開始。會帶讀者從 code level 了解 conductor 如何 call scheduler 到 scheduler 怎麼做決定流程。 本篇文章以撰寫時最新 stable 版本 victoria 為基礎。 nova-scheduler 簡介 nova-scheduler 是設計成一個 plugin based 的 scheduler，使用者可以根據自己的需求撰寫自己的 scheduler driver。在 nova 中預設會啟用的是本身 nova code base 中提供的 filter scheduler。 Filter scheduler 的運作原理非常的簡單，基本上會將所有的 host 經過一系列的 "filter"，如果不符合 filter 的條件就會被剔除，符合的就會通過，並且進入最後的選擇的 pool。這些通過 filter 的 host 會在做 […]
Cloud
KubeVirt 架構介紹
前幾日在 Cloud Native Taiwan User Group 久違的講了一場 KubeVirt 101，越玩越覺得這個計畫還真有趣。在這裡打算把 KubeVirt 101 講的內容稍微濃縮一下，將重點放在架構的地方來寫一篇介紹。推坑大家來玩玩這個在 Kubernetes 上跑 VM workload 的 operator。 基本介紹 官網原文: KubeVirt is a virtual machine management add-on for Kubernetes. The aim is to provide a common ground for virtualization solutions on top of Kubernetes. 簡單來說 KubeVirt 是一個讓使用者能夠在 Kubernetes 上跑虛擬機應用的 Kubernetes operator，讓使用者可以跑一些還沒容器化或是需要特殊 kernel 的應用。最大的好處在於維運上所有概念都跟一般的 Kubernetes container […]
日本 LINE 工作三個月心得
各種因緣際會下， 2019 年年底來到日本，2020 一月入社後，也要在日本領第三份薪水了。從大學畢業後一路當兵又進來當新卒，很久沒有寫文章了。趁最近因為疫情關係 Work From Home，空閒時間比較多，來記錄一下第一份也是第一次來國外工作的心得。本篇主要講講來日本生活三個月的一些心得，除了工作外也會包含下班放假的休閒生活。 為甚麼選擇到日本 LINE 當初在大四上的時候因緣際會得知 LINE 有 Infrastructure Engineer 的職缺，被社群夥伴問了要不要去面面看。當初 Google 轉正職的流程也還沒跑完，想說就面面看多個經驗也不錯。詳細的面試過程可以參考這篇: LINE Tokyo 面試心得。沒想到面試過了，當初在跟彰化 Google 的 offer 猶豫了很久。最後雖然來到 LINE 能夠存的錢比較少，也要脫離原本的交友圈，但考慮到工作內容和未來職涯發展性還是選擇到 LINE 來就職。 工作文化 LINE 基本上工作文化比較不像個人印象中的傳統日本公司，每天穿西裝、對長官要非常尊敬、下班要賠上司喝酒等，反而比較偏向外商的感覺。工程師上班基本上不需要穿西裝打領帶，同事們都是穿著比較休閒的衣服來上班，下班後也沒有要去跟主管喝酒應酬。 上班是採彈性工時，雖然需要打卡，但是基本上是責任制。大部分同事都大約 11 點左右才來上班，如果家裡有事無法出門平時也能 Work From Home，非常的自由。不過我們團隊似乎蠻多工作狂的，有時會看到有人下班了還在送 pull request，回訊息等等，但我個人通常都是下班後除非緊急事件不太會處理公司事情的。 同事互動溝通 同事之間溝通基本上都是使用英文為主，畢竟我們團隊 13 人裡面有 7 人都不是日本人，所以也不用擔心不會日文的問題。不會日文最大的缺點大概就是有時候比較難跟日本同事閒話家常，不過還是可以跟團隊內台灣人、中國人用中文聊天。除此之外，公司也有提供免費的日文、英文、韓文課，有興趣的話都可以去申請參加。 同事之間相處都還蠻融洽的，有問題詢問也都非常有問題詢問也都非常樂意回答，也會一起幫忙找 solution，有時候聽了同事想法都會想到意想不到的一些解法。 工作環境 LINE 的工作環境非常舒適，可以參考一下LINE Fukuoka 工作環境的介紹，裡面有些照片可以參考，東京辦公室基本上長得差不多。每個人基本上一個蠻大的電動升降桌，坐的椅子是 Herman Miller Aeron，大部分人都會選擇申請兩台 […]
Calico 基本架構介紹
Calico 是一個純 L3 的 Datacenter 網路方案，跟 Kubernetes, OpenStack 都有非常好的整合，也是 Kubernetes 常用的 CNI 之一。本篇文章將會介紹 Calico 基本元件以及架構。 基本元件 Calico 由下列獨立的元件組成： Felix，跑在每一台 endpoint 的 Calico Agent Orchestrator plugin，將 Calico 整合至不同 orchestrator 的 code etcd，用來儲存資料 BIRD，發布 routing 資訊的 BGP Agent BGP Route Reflector，在比較大的網路環境需要 RR 接下來會一一介紹這些元件。 Felix Felix 是跑在每一台提供 endpoint 主機上面的 daemon，在多數情況下是指那些運行 VM 或是 container 的主機。Felix 負責設定路由跟 ACL 等功能，基本上負責任和需要在主機上以提供網路連線相關的設定。 根據不同的平台，Felix […]
RDMA over Commodity Ethernet at Scale – 論文導讀
在上一篇文章 RDMA Overview 中簡單了介紹了一下 RDMA 這個技術，這次將為 Microsoft 在 2016 年 SIGCOMM 發表關於他們資料中心大規模應用 RDMA 所撰寫的論文 RDMA over Commodity Ethernet at Scale 做簡單的導讀。 Abstract Over the past one and half years, we have been using RDMA over commodity Ethernet (RoCEv2) to support some of Microsoft’s highly-reliable, latency-sensitive services. This paper describes the challenges we encountered during the […]
RDMA Overview
Latency problems are harder because the speed of light is fixed; you can’t bribe God —David Clark 近年來網路頻寬雖然大幅提升，kernel 處理封包的能力卻沒有顯著提高。為了更進一步提高頻寬跟降低延遲，RDMA 和 DPDK 等技術出現，跳過了 kernel 直接處理 packet。本篇將會介紹現今 RDMA 相關的技術，比較，以及一些問題。 High Level Overview RDMA 技術基本上都是把 transport layer offload 到網卡上，避免使用 kernel 做封包處理，把 CPU 從 critical path 中拿除。顧名思義，這可以讓設備直接寫入其他設備的虛擬記憶體，在可控制的環境中達成 10 毫秒左右的傳輸延遲。但是傳統的 RDMA 有兩個很大的缺點： 需要支援 RDMA 的 lossless network，也就是 Infiniband 因而需要在環境中額外放 Infiniband […]
LINE Tokyo 面試心得
因緣際會之下在社群朋友的介紹下得知 LINE 有在找 Private Cloud 的 Infrastructure Developer Engineer。剛好 LINE 也使用 OpenStack 並且正在導入 Kubernetes，是我本身經驗比較多的領域，也即將在 2019 大學畢業，就抱著就算沒有上也能增加經驗的想法投了履歷。目前也已經面試完畢並且拿到 offer，決定來寫一篇介紹一下 LINE 面試過程以及一些心得給有興趣加入 LINE 的人參考。 面試內容 職缺：インフラ開発エンジニア(Private Cloud プラットフォーム) 翻譯成英文大概是 Infrastructure development engineer (Private Cloud platform) 面試方式：Skype Pre-test 面試前會有一次簡單的 pre-test，裡面會有幾題簡單的 coding 題目。寫完後後面會需要提供一些資訊，包括對各種 coding 相關 tool 的熟悉度，跟一些面試原因等很基本的問題。大概花個一個小時左右就能夠寫完了，不過寫到的內容後續面試可能會被問到，要注意一下。 第一次面試 第一次面試會是工程師來面試，問題的內容會比較 technical 導向。面試的問題就我來說基本上都是履歷上寫到的經驗，不過我的部分可能比較沒有參考價值，因為我經驗大多都注重在 OpenStack 上面，又因 LINE 的 private cloud 也是用 OpenStack 建的，因此大部分內容都是 […]
Ceph and OpenStack – Best Practices Part II
上個禮拜介紹了 Ceph and OpenStack – Best Practices Part I，而這次要接續之前的建議再多介紹幾個 Ceph 跟 OpenStack 整合的最佳實踐。額外使用這些設定可以更加的整合 OpenStack and Ceph。 使用 RAW Image 在前一篇 Ceph and OpenStack – Best Practices Part I 中介紹了 RBD 本身有 layering 的功能，不過這個功能是有些限制的。上傳到 OpenStack 的 Image 必須是 RAW 格式才會利用到 RBD layering。所以會建議所有上傳上去的 image 都先轉成 RAW 格式。透過 qemu-img 指令可以很容易的轉換各種格式： qemu-img convert image.qcow2 image.raw 之後將 RAW 格式的 image […]
Ceph and OpenStack – Best Practices Part I
Ceph and OpenStack 現在已經是 IaaS 中成雙成對的一個組合。根據 2017 年 6-12 月的 OpenStack User Survey，在所有 OpenStack Deployment 中，有 57% 的部署使用的 Cinder backend 為 Ceph RBD。當然在使用 Ceph 作為 OpenStack Glance, Cinder 的 backend 會有一些能夠在設定上調整的最佳實踐。本篇文章將會介紹這些如何調整以及為什麼要進行這些設定。 在 Glance 中使用 show_image_direct_url 使用 Ceph RBD 時，預設會開啟 RBD Layering 這個功能，可以把它想像成一個可以讀寫 snapshot。這會建立一個原本 image 的 clone，而 Ceph 就只會建立跟原本 image 不同部分的 RADOS Objects。這代表了兩件事： 省空間 — 因為只會建立相對原本 […]
Container vs VM: When and Why?
Container 跟 Virtual Machine 的使用時機在網路上已經被討論了很久。每個人都有自己的看法和意見，有些人支持純 Container，有些支持純 VM，也有些支持 Container on VM。本篇文章將以個人看法針對 Container vs VM 做介紹跟其適用的使用時機做論述。 Container Container 在這 5 年來快速竄紅，憑的是其輕量化和快速部署的彈性。與其虛擬化整個硬體，Container 透過 cgroups 跟 namespace 將 host OS 的資源做隔離，也有人稱之為 OS 的虛擬化。 Container 共用 host 上的 kernel，只有其獨立的 binary 跟 libraries，所以比起 VM 在 image 大小跟啟動速度都快的許多。 Container 的優點： Image 很小：因為跟 host 共用 kernel，只需要提供需要的 OS 元件跟 libraries。 速度：部署極快，通常花數秒就可以生成一個 container。 可攜性：在正確的 kernel […]