Generated by All in One SEO v4.9.10, this is an llms.txt file, used by LLMs to index the site.

# Gene WorkSpace

Cloud Native, OpenStack, Ceph

## Sitemaps

- [XML Sitemap](https://igene.tw/sitemap.xml): Contains all public & indexable URLs for this website.

## Posts

- [Intel Arc Pro B60 & B50 評測：24GB vs 16GB Homelab GPU](https://igene.tw/intel-arc-pro-b60-vs-b50-review) - B60 和 B50 用的是同一顆 Battlemage G21 晶片，media engine 一樣，SR-IOV 支援一樣，差別就是 VRAM：B60 24GB，B50 16GB。這個差距在某些工作上其實蠻具體的，在某些工作上又幾乎感覺不到。 兩張卡都在同一台 host 上跑，所以比較數字反映的是卡本身的差異，不是平台造成的。 測試平台 Host OS： Proxmox VE，Debian GNU/Linux 13 (trixie)，kernel 6.17.13-2-pve CPU： AMD EPYC 平台（雙插槽） RAM： 128GB ECC Driver stack： xe B60： Intel Arc Pro B60 24GB（PCI ID 8086:e211，sriov_totalvfs=7） B50： Intel Arc Pro B50 16GB（PCI ID 8086:e212，sriov_totalvfs=2） Container images： vllm-xpu-env（vLLM 0.17.2.dev，本地自建）、linuxserver/ffmpeg:latest
- [告別 ingress-nginx：Cilium Gateway API 遷移筆記](https://igene.tw/cilium-gateway-api-migration) - 前陣子看到 ingress-nginx 宣布 deprecated，其實也不太意外，Kubernetes 官方推 Gateway API 也推了好一陣子了。我的叢集上跑著六個服務，一直都是用 ingress-nginx 做路由，於是趁這個機會全部遷移到 Cilium Gateway API。 本文記錄遷移過程和途中踩到的幾個坑。 環境 CNI：Cilium v1.18.6 TLS：cert-manager（Helm） DNS-01 Provider：Cloudflare Gateway API 快速介紹 在開始之前先簡單說明 Gateway API 的三個主要資源，不然後面看 YAML 會有點迷失。 GatewayClass 定義 Gateway 的實作方式，概念上類似 Ingress 的 ingressClassName。Cilium 安裝後會自動建立一個叫 cilium 的 GatewayClass。 Gateway 代表一個實際的 load balancer。一個 Gateway 可以有多個 listener，每個 listener 對應一個 port/protocol/hostname 的組合。 HTTPRoute 定義路由規則，指定流量要送到哪個 Service。跟 Ingress
- [六千多的雲端伺服器顯卡！Nvidia Tesla T10 實測分享](https://igene.tw/nvidia-tesla-t10-gpu-review) - 近期在中國閒魚發現了一款特別的顯示卡 - Tesla T10。這款原本用於 GeForce NOW 雲端遊戲伺服器的專業級 GPU，目前以約 1350 人民幣（190 美金）的價格在二手市場販售。本文將深入分析這張顯示卡的效能表現、散熱特性，並分享實際使用心得，協助您評估是否值得購入。
- [在 Arista 交換機上部署 Prometheus 監控系統](https://igene.tw/prometheus-exporters-on-arista-eos) - 詳細介紹如何在 Arista 交換機上使用 Docker 容器部署 Prometheus 監控系統，包含 node_exporter 和 snmp_exporter 的完整設定步驟、存取控制清單配置，以及如何驗證監控服務是否正常運作的測試方法。適合網路工程師參考使用。
- [RDMA Overview](https://igene.tw/rdma-overview) - 近年來網路頻寬雖然大幅提升，kernel 處理封包的能力卻沒有顯著提高。為了更進一步提高頻寬跟降低延遲，RDMA 和 DPDK 等技術出現，跳過了 kernel 直接處理 packet。本篇將會介紹現今 RDMA 相關的技術，比較，以及一些問題。
- [Ceph and OpenStack – Best Practices Part II](https://igene.tw/ceph-and-openstack-best-practices-ii) - 上個禮拜介紹了 Ceph and OpenStack – Best Practices Part I，而這次要接續之前的建議再多介紹幾個 Ceph 跟 OpenStack 整合的最佳實踐。額外使用這些設定可以更加的整合 OpenStack and Ceph。
- [Ceph and OpenStack - Best Practices Part I](https://igene.tw/ceph-and-openstack-best-practices) - OpenStack Deployment 中，有 57% 的部署使用的 Cinder backend 為 Ceph RBD。使用 Ceph 作為 OpenStack Glance, Cinder 的 backend 會有一些能夠在設定上調整的最佳實踐。本篇文章將會介紹這些如何調整以及為什麼要進行這些設定。
- [從裸機到雲端：OpenStack 介紹 2](https://igene.tw/openstack-intro-2) - 前一篇文章以比較非技術角度介紹了 OpenStack 這個專案。今天開始要以比較技術的角度來介紹 OpenStack。首先本篇會先來大致介紹 OpenStack 所組成的元件，後續幾篇將會是各個元件的深入介紹。 OpenStack 核心功能 OpenStack 是由非常多的服務構成的，每個服務會由一個元件所提供，而這個元件底下又可以切割成不同的 microservice。 其中有部分服務被 OpenStack 官方標記為核心功能，為上圖中粗體的專案，我們在這裡列出核心功能的元件名稱，其提供的服務以及相似功能的 AWS 服務： Nova：運算服務 (Compute Service) AWS EC2 Neutron：網路服務 (Networking) / AWS VPC Keystone：身分服務 (Identity Service) / AWS IAM Cinder：區塊儲存服務 (Block Storage) / AWS EBS Glance：映像檔服務 (Image Service) / AWS AMI Ironic：裸機部屬服務 (Baremetal Provisioning Service) / AWS EC2 Baremetal Horizon：儀錶板 (Dashboard) /
- [在 Proxmox VE 上使用 Nvidia vGPU](https://igene.tw/proxmox-ve-nvidia-vgpu) - 前幾週在中國的二手平台上看到了很便宜的 Nvidia Tesla P4，由於 Tesla P4 是半高單槽顯示卡，又不需要額外插電，非常適合放在 1U 伺服器上做使用，於是就買了幾張來測試 vGPU 看看。本篇將會介紹如何在 Proxmox 上使用 Nvidia 的 vGPU 功能。
- [FOSDEM 2023 回顧](https://igene.tw/fosdem-2023) - 在忙著畢業找工作後又經過 3 年的疫情，已經很久沒有參加過國外的大型會議了。這次看到 [OCF](https://ocf.tw) 有要去 FOSDEM 擺攤並且將能部分補助參與經費，思考了一下決定來參加看看這場歐洲大型的開放原始碼相關會議
- [透過 Ingress Nginx 公開 TCP/UDP 服務](https://igene.tw/exposing-tcp-udp-ingress-nginx) - Ingress Nginx 在 Kubernetes 中常被利用來提供網頁服務的反向代理和 load balancing。在一些狀況下，你可能會需要同一個 IP 也能夠提供其他 TCP/UDP 服務。這篇文章將會介紹在這種狀況下如何透過 Ingress Nginx 來作為 TCP/UDP 服務的 proxy。
- [Kubernetes Cluster-API 介紹](https://igene.tw/kubernetes-cluster-api-intro) - Kubernetes 在雲原生世界發展這麼多年，也發展出了很多管理其集群生命週期的相關專案，如 kops, Rancher 等。而 VMware 則發起了一個名為 Cluster-API 的專案來利用 Kubernetes 本身的功能管理其他 Kubernetes 集群。本篇文章將會來簡單介紹 Cluster-API 這個專案。
- [如何挑選適合 Ceph 的 SSD](https://igene.tw/choosing-ceph-ssd) - 隨著SSD價格的不斷下降，許多技術愛好者和企業開始考慮使用 Ceph 建立基於 SSD 的儲存池，以追求更高的效能。但要確保 Ceph 達到出色的效能，選擇合適的 SSD 極為關鍵。在本篇中，我們將探討如何選擇適合 Ceph 的 SSD。
- [快速部署 Kubernetes 叢集：使用 kops 在 OpenStack 上的實踐指南](https://igene.tw/k8s-on-openstack-with-kops) - Kubernetes 提供多種部署選擇，而在眾多工具中，kops 以其易用性及高整合性脫穎而出。本文將深入介紹 kops 工具，並透過實際操作引導讀者在 OpenStack 環境中迅速建立一個 Kubernetes 叢集。
- [部署 Charmed Kubernetes with OpenStack Integrator](https://igene.tw/charmed-kubernetes-with-openstack-integrator) - Charmed Kuberenetes 是 Canonical 提供的 Kubernetes 部署方式，可以透過 juju 將 Kubernetes 部署至各種不同環境。 本篇將介紹如何部署 Charmed Kubernetes 至 OpenStack 上，並且利用 OpenStack Integrator 使用 OpenStack 提供 Persistent Volume 和 Load Balancer 給 Kubernetes 使用。
- [Linux PSI (Pressure Stall Information) 指標的解讀與應用](https://igene.tw/pressure-stall-information-intro) - 當 CPU、記憶體或 I/O 裝置發生競爭時，工作負載會經歷延遲峰值、吞吐量損失，並且面臨 OOM 終止的風險。在沒有準確測量此類競爭的情況下，使用者被迫要麼保守地運用他們的硬體資源，要麼冒險經常遭受因過度設定而引起的中斷。在 Linux kernel 4.20 之後，Linux kernel 加入了 PSI (Pressure Stall Information) 這個資訊，讓使用者可以跟精確的了解到資源不足對整個系統的效能影響。本篇文章將會簡單介紹 PSI 跟如何解讀其資訊。
- [如何監控 container 的 PSI 資訊](https://igene.tw/monitor-container-psi) - 在[上一篇文章](https://igene.tw/pressure-stall-information-intro)中，我們探討了 PSI (Pressure Stall Information) 以及如何監控系統的 PSI 資訊。本文將深入探討如何監控單一 container 的 PSI 資訊。
- [AMD GPU 與深度學習：實用教學指南](https://igene.tw/amd-gpu-deep-learning-practical-guide) - 過去經常聽說 AMD GPU 用於執行深度學習相關軟體非常麻煩，建議有深度學習需求的使用者購買 Nvidia 顯卡。然而，最近 LLM（大型語言模型）很熱門，許多研究單位釋出了基於 LLaMA 的模型，讓我覺得有趣並想測試。我手邊有較多 VRAM 的顯示卡都是 AMD 的，因此決定嘗試使用這些顯示卡來執行。
- [在 Kubernetes 上利用 Nvidia GPU 部署 LLM Chatbot](https://igene.tw/llm-chatbot-on-kubernetes) - 隨著人工智慧技術的快速發展，越來越多的企業和開發者希望在自己的系統中整合語言模型聊天機器人（LLM Chatbot）。本文旨在引導讀者如何在 Kubernetes 環境中使用 Nvidia GPU，來部署一個高效能的 LLM Chatbot，從安裝必要的驅動和工具到具體的部署步驟，逐一介紹。
- [KubeVirt 架構介紹](https://igene.tw/kubevirt-architecutre) - 前幾日在 CNTUG 久違的講了一場 KubeVirt 101，越玩越覺得這個計畫還真有趣。在這裡打算把 KubeVirt 101 講的內容稍微濃縮一下，將重點放在架構的地方來寫一篇介紹。推坑大家來玩玩這個在 Kubernetes 上跑 VM workload 的 operator。
- [從裸機到雲端：OpenStack Nova 介紹 1](https://igene.tw/openstack-nova-intro-1) - 昨天的文章給予了讀者 OpenStack 的架構一個大致的介紹，今天要來開始深入介紹各個元件。我們首先將由 OpenStack 提供的最核心功能：運算功能 (Compute Service)，也就是開虛擬機器 (Virtual Machine) 功能的元件開始，也就是 Nova。 什麼是 Nova？ Nova 是 OpenStack 其中一個專案，它負責提供一個方式來生成 (provision) 運算機器，目前主要同時支援虛擬機器和實體主機 (透過 Ironic)。Nova 作為一組 daemon 運行在現有 Linux 服務器之上，以提供該服務。在稍後的章節會介紹 Nova 各個 daemon 所負責的工作。 目前 Nova 的基本功能需要搭配以下的 OpenStack 服務才能使用： Keystone Glance Neutron Placement 在上一篇中沒有介紹的 Placement，這裡快速的簡介一下。 Placement 是從 Nova 中拆分出來的服務，主要功能是追蹤不同類別的可用資源和其使用量，例如：CPU, RAM 等等。 對使用者來說 你可以透過 Nova 所提供的工具或 API 來建立和管理運算資源 使用 Nova
- [Podman 介紹](https://igene.tw/podman-intro) - Podman 曾經是 CRI-O project 中的一部分，後來被分離出成為一個獨立 project, libpod。Podman (Pod Manager) 的目標是提供一個跟 Docker 相似體驗的 container CLI，提供給使用者創立和運行 container。
- [從裸機到雲端：OpenStack Neutron 介紹 — OVN 架構](https://igene.tw/openstack-neutron-ovn-arch) - 上篇介紹了 OVN，本篇要來進入 OVN Plug-in 在 OpenStack 中的參考架構。 架構布局 參考架構中將 OVN 元件拆分成 4 個不同種類的節點各自負責不同任務 Controller Node Controller node 主要提供以下功能： 1 個 management interface 認證服務 (Keystone) 映像檔服務 (Glance) 透過 OVN ML2 mechanism driver 進行網路管理 (control plane) 運算資源管理 (Nova control plane) Database Node Database node 主要負責 OVN 相關 databse，包含以下元件： 1 個 management interface ovn-northd OVN northbound database OVN
- [從裸機到雲端：OpenStack Neutron 介紹 — Linux Bridge Provider Networks](https://igene.tw/openstack-neutron-linux-bridge-provider) - 上篇介紹了 Neutron 的架構，再接下來幾天會介紹 Neutron 使用 Linux Bridge 跟 OVS plug-in 時的架構以及流量是怎麼流的。首先第一篇筆者會先來介紹 Linux Bridge with Provider Network。 Linux bridge: Provider networks Provider network 架構示例使用 VLAN (802.1q) tagging 在實例 (instance) 和實體網路基礎設施之間提供 L2 連接。 它支援一個 non-tagged（扁平）網路和多達 4095 個 tagging (VLAN) 網路。 VLAN 網路的實際數量取決於物理網絡基礎設施。 架構 這張圖畫出了在單一 provider network 下 compute node 中的元件是怎麼串接的。在這個範例中 Instance 跟 DHCP agent 是在同一台的，但是在實際狀況下 DHCP agent
- [從裸機到雲端：OpenStack Neutron 介紹 — OVS Provider Networks](https://igene.tw/openstack-neutron-ovs-provider) - 上篇介紹了 Neutron 使用 Linux Bridge plug-in 在不同狀況下的架構以及流向，接下來幾天會介紹 OVS plug-in 時的架構以及流量是怎麼流的。首先第一篇筆者會先來介紹 Open vSwitch with Provider Network。 Open vSwitch: Provider networks 架構 這張圖畫出了在單一 provider network (untagged/flat) 下 compute node 中的元件是怎麼串接的。在這個範例中 Instance 跟 DHCP agent 是在同一台的，但是在實際狀況下 DHCP agent 有可能是在其他 compute node 上。 在有多個 Provider networks 的狀況下，每一個 provider networks 會使用同一個 OVS provider bridge 跟 integration bridge，但是會用不同的 internal VLAN 隔離。Internal
- [部署 Kolla-Ansible 使用 External Ceph](https://igene.tw/kolla-ansible-external-ceph) - 在部署 Kolla-Ansible 時，雖然能夠同時部署 Ceph Cluster，但是在一些情況下，維運人員會希望將 Ceph 跟 OpenStack 分開管理。本篇文章將會介紹如何使用 Kolla-Ansible 和其 config override 的功能部署 OpenStack 並使用外部的 Ceph。
- [在 Kolla-Ansible 使用 Custom Config](https://igene.tw/kolla-ansible-custom-config) - Kolla-Ansible 部署 OpenStack 的方法，在設定的部分全部都是在 globals.yml 中設定。不過這樣的方式不免在部署中顯得稍失彈性，無法根據特殊環境做客製化本篇文章將會介紹如何使用 config override 來更改 Kolla-Ansible 部署 OpenStack 的設定檔。
- [透過 Kolla-Ansible 跟 Container 部署 OpenStack](https://igene.tw/kolla-ansible-deploy) - OpenStack 早期在部署方面相當複雜也難以維護，但是在近期 OpenStack Community 中也出現了透過 Container 跟 Ansible 部署的方式。這種方式就是透過 Kolla 跟 Kolla-Ansible 實現。本篇文章將會介紹如何透過這個專案快速部署一個 OpenStack 環境
- [從裸機到雲端：OpenStack 部屬工具 3](https://igene.tw/openstack-deployment-tools-3) - 上一篇我們介紹了兩個有強大廠商後盾的部屬工具，本偏要介紹大多為社群成員維護的部屬專案，OpenStack-Ansible, Kolla-Ansible, OpenStack-Helm OpenStack-Ansible OpenStack-Ansible 就如其名，就是透過 Ansible 去部屬 OpenStack 的工具，其中支援非常多 OpenStack 元件以及不同的 Plugin。 OpenStack Ansible 主要透過 lxc container + Ansible-playbook 來安裝 OpenStack，其中有部分 service 並沒有放在 lxc container 中，如 nova-compute。 在 network plugin 的支援也是今天介紹的 3 個部屬工具中最多的，其中包含了在一些特殊環境下很好用的 Calico。 OpenStack Ansible 除了部屬 OpenStack 以外，同時也可以在部屬 OpenStack 儲存所需要使用的 Ceph，而其他專案如 Kolla-Ansible 的 Ceph cluster 就要額外自己部屬並且透過 config overwrite 去設定。 Kolla-Ansible Kolla-Ansible 是本次系列文章所選用的部屬工具，跟 OpenStack-Ansible
- [從裸機到雲端：OpenStack 部屬工具 2](https://igene.tw/openstack-deployment-tools-2) - 上一篇我們介紹了 DevStack 跟 MicroStack 這兩個非常容易上手但是比較偏向開發測試使用的部屬方式。今天筆者會來介紹 TripleO 跟 OpenStack Charms 這兩個有強大廠商後盾的部屬工具 TripleO TripleO 是 "OpenStack on OpenStack" 的縮寫。它是 OpenStack 中其中一個 project，其主要功能就是透過 OpenStack 的一些元件幫你部屬以及維運一個可用於實際生產環境的 OpenStack Cloud。 目前 TripleO 主要由 RedHat 維護，也是 RedHat OpenStack Platform (RHOSP) 的上游部屬專案 架構概覽 如剛剛所提到的，TripleO 是 "OpenStack on OpenStack"，亦即是你會有兩個 OpenStack 環境。其中一個環境我們稱之為 undercloud。Undercloud 包含了一些必要的 OpenStack 元件用來部屬我們的 overcloud。Overcloud 是 undercloud deploy 出來的 OpenStack cluster，可以被用來 production, staging,
- [從裸機到雲端：OpenStack 部屬工具 1](https://igene.tw/openstack-deployment-tools-1) - 前面三周都在介紹雲端的概念以及 OpenStack 的架構，今天開始要實際進入 OpenStack 部屬相關的一些介紹。首先筆者會介紹一些 OpenStack 常見的部屬工具。 OpenStack 部屬工具 OpenStack 部屬工具有非常多種，每種適用的架構跟環境都不太一樣，在這兩篇文章筆者會帶過一些常見的 OpenStack 部屬工具，其中包含以下： DevStack MicroStack TripleO OpenStack Charms OpenStack-Ansible Kolla-Ansible OpenStack-Helm DevStack "DevStack" 顧名思義就是要拿來給 "Dev" 來用的，其主要目的是提供 OpenStack 開發者一個能夠快速測試其功能的環境。 DevStack 基本上就是一系列的 shell script，而預設會使用基於 git master 的最新版本快速部屬出一個完整的 OpenStack 環境。主要用途就是拿來當一個可互動的開發環境，以及上游 OpenStack 元件中 functional testing 的基礎。 MicroStack MicroStack 是甚麼? An OpenStack Environment in 2 commands MicroStack 是個讓你下兩個指令就能夠生成一個基本 OpenStack 環境的專案。能夠大大減輕
- [MicroStack — 30 分鐘內建立 OpenStack 環境](https://igene.tw/microstack-openstack-in-30-mins) - 近幾年仍然有很多人認為 OpenStack 是個很難安裝的軟體，但是事實並不是這樣的。在 Kolla-Ansible, OpenStack-Ansible 等計畫出現後，OpenStack 的安裝跟設定其實成為一件非常容易的事情。而這次就來要介紹一個將 OpenStack 安裝更為簡化的專案，MicroStack。
- [從裸機到雲端：OpenStack Cinder 介紹](https://igene.tw/openstack-cinder-intro) - 今天我們要來介紹最後一項 OpenStack 元件，Cinder。Cinder 也是常見 OpenStack 部屬會提供的服務，也是 OpenStack 核心專案之一，我們就來一起看看 Cinder 提供了什麼服務以及其架構長得怎麼樣。 Cinder 是什麼？ 在官方文件中是這麼說的： Cinder 是 OpenStack Block Storage 服務，用於為 Nova 虛擬機、Ironic baremetal、container 等提供 volume。 你可以把 Cinder 想像成一個提供硬碟的服務，他提供了一個 API 讓你可以在 Instance 上掛載硬碟，以提供儲存空間。除了單純的提供區塊式儲存到硬碟外，Cinder 額外的也提供了 volume snapshots 跟備份的功能，同時也能利用 volume type 管理不同的後端或儲存空間。 Cinder 本身設計的目標是： 基於 microservice 的架構：讓開發者能夠快速添加新功能 高度可用：可擴展到非常高的工作負載 容錯：隔離的 process 避免連動式的故障 Recoverable：Admin 可以很容易的發現，調整，解決問題 開放標準：成為社區驅動的 API 的參考實作 Cinder 架構 Cinder
- [從裸機到雲端：OpenStack Glance 介紹](https://igene.tw/openstack-glance-intro) - 在經過了好幾篇的 Neutron 之後我們終於來到下一個 OpenStack 核心專案，這次要介紹的是大家常常忽略，但是卻又很重要的 Glance。 Glance 是什麼？ 在官方文件的定義中是這麼說的： Image service (Glance) 提供讓使用者可以上傳和發現目的在於與其他服務一起使用的數據資產。目前提供的是映像檔 (Images) 和 metadata definitions。 簡單來說，Glance 就是一個讓你儲存和下載映像檔和 metadata definitions 的服務。 映像檔 Glance 映像服務包括搜尋、上傳和下載虛擬機 (VM) 映像檔。 Glance 有一個 RESTful API，提供使用者查詢 VM 映像檔 metadata 以及下載實際的映像檔資料。 而儲存映像檔的方式可以有非常多種，目前常見的為：local filesystem, Ceph, Swift 等等。 Metadata Definitions Glance 在儲存映像檔的同時也可以儲存一個 Metadata Definitions 目錄 (Catalog)。 這為 OpenStack 的其他服務提供了一種以 API call 確定可應用於 OpenStack
- [從裸機到雲端：OpenStack Neutron 介紹 — OVN vs OVS](https://igene.tw/openstack-neutron-ovn-vs-ovs) - 上一篇講述了 OVN Plug-in 在 OpenStack 中的參考架構，本篇要來比較在 OpenStack Neutron 中使用 OVN 跟 OVS 的主要差異 架構面 這個從官方 FAQ 中翻譯的表格可以很清楚的看出 OVN 跟 OVS 的架構面差異 項目 ml2/ovs ml2/networking-ovn agent/server 之間的溝通 RabbitMQ message + RPC NorthBound 跟 SouthBound databases 之間的 ovsdb protocol l3HA API 在 deployment 的時候可以設定 router 中的 ha field 以便開啟或關閉 l3HA 在有多個 network node 時自動開啟 HA 功能 DVR
- [從裸機到雲端：OpenStack 介紹 1](https://igene.tw/openstack-intro-1) - 我們在前幾一篇文章敘述本次鐵人賽所會架出的雲端架構了，今天開始的文章將會介紹使用的 IaaS Layer: OpenStack，本次文章將會從 overview 開始，之後的文章將會針對一個個 OpenStack 元件做細部介紹。 Reference 本系列文章會大量利用到 OpenStack 自己本身的 Document 作為 reference 跟圖片來源。 想更了解 OpenStack 概念的可以去官方文件直接閱讀 OpenStack 是什麼? 要討論 OpenStack 是什麼我們可以從三個面向： 軟體 (Software) 社群 (Community) 群組 (Group) 軟體 OpenStack 基本上是一個能夠提供私有雲跟公有雲服務的軟體套件，其中包含了多種不同的應用狀況如一般企業、電信商、高效能運算等。 從軟體的角度看，OpenStack 是由多個微服務 (micro service) 組成，而使用者可以根據其應用情境去組合這些服務以達到自己的需求。這些服務基本上是透過 REST API 提供，另外也有提供不同程式語言的程式開發套件 (Software Development Kit) 來取用服務。 這些軟體可以透過官方提供的 tarball 進行安裝，另外在各大 Linux 發行版的套件管理工具中也都有包好的套件。 OpenStack 軟體地圖： 社群 在軟體之外，OpenStack 其實也是個龐大的社群，而這個社群的目標是：
- [從裸機到雲端：OpenStack Neutron 介紹 — Linux Bridge - Self-Service Networks](https://igene.tw/openstack-neutron-linux-bridge-self-service) - 上篇介紹了 Linux Bridge with Provider Network 的架構及封包流向，今天這篇會來介紹 Linux Bridge with self-serivce networks。 Linux bridge: Self-service Networks Self-service networks 提供使用者幾乎無限數量的虛擬網路。 Neutron 雖然有支援 VLAN self-service networks，但本例以 VXLAN self-service networks 為例。 架構 上圖為 Linux Bridge - Self-service networks 架構下的整個架構總覽，可以看到那些元件是跑在 controller node 上，哪些是在 compute node 上，哪些是在 network node 上。 這張圖畫出了在單一 provider network 下 self-service networks 中所使用的的元件是怎麼串接的。在這個範例中 Instance 跟 DHCP
- [從裸機到雲端：OVN 介紹](https://igene.tw/ovn-intro) - 前幾篇筆者介紹了 OpenStack 在使用 Linux Bridge 和 Open vSwitch plug-in 下的相關架構，這篇我們要來介紹一個比較新，架構比較不一樣的 Neutron Plug-in，OVN。 Overview OVN 可以說是一個透過 OVS 建立虛擬網路的分散式 SDN controller。以下回一些 OVN 所能提供的功能 透過 L2 跟 L3 overlays 為 OVS 提供一個抽象層，同時可以管理與實體網路的連接 支援利用 OVS connection tracking 實現的靈活 ACL 支援透過 OVS flow 實現的分散式 L3 路由，同時支持 IPv4 和 IPv6 利用 OVS connection tracking 的 NAT 跟 Load balancing 分散式的 DHCP
- [從裸機到雲端：OpenStack Neutron 介紹 — OVS Self-service Networks](https://igene.tw/openstack-neutron-ovs-self-service) - 上篇介紹了 Open vSwitch with Provider Networks 的架構及封包流向，今天這篇會來介紹 Open vSwitch with self-serivce networks。 Open vSwitch: Self-service Networks 架構 上圖為 Open vSwitch - Self-service networks 架構下的整個架構總覽，可以看到那些元件是跑在 controller node 上，哪些是在 compute node 上，哪些是在 network node 上。 這張圖畫出了在單一 untagged (flat) provider network 和單一 self-service networks 下其中所使用的的元件是怎麼串接的。在這個範例中 Instance 跟 DHCP agent 是在同一台的，但是在實際狀況下 DHCP agent 有可能是在其他 compute node 上。 Traffic Flow
- [從裸機到雲端：OpenStack Neutron 介紹 3](https://igene.tw/openstack-neutron-intro-3) - 上一篇介紹了 Neutron 的網路的概念，接下來將會接續介紹 Neutron 的一些名詞。 Neutron 概念 (名詞) Subnets (子網) Subnets 是一組 IP 地址和其相關的設定狀態，其功能是為 provider/project networks 提供 IPAM（IP 地址管理）的功能。 子網用於在網絡上創建連接埠時分配 IP 地址。 Subnet pools 使用者通常可以使用任何有效的 IP 地址創建子網，而沒有其他限制。 但是，在某些情況下，管理員或 project 會希望預先定義一個地址池 (IP address pool)，使在創毽子網的時候自動分配一段地址。在一些狀況下管理員可能想避免 IP 地址重複，就可以使用 subnet pools 防止來自同一池的兩個子網的地址重複。 Port (連接埠) 連接埠是將單個設備（例如虛擬伺服器的 NIC）連接到虛擬網路的連接點。 該連接埠還描述了相關的網路設定，例如要在該連接埠上使用的 MAC 和 IP 地址。 路由器 (Router) 路由器提供虛擬的 L3 功能，例如self-service 跟 provider 網路之間或是
- [從裸機到雲端：OpenStack Neutron 介紹 2](https://igene.tw/openstack-neutron-intro-2) - 上一篇介紹了 Neutron 的架構，接下來兩篇將會接續介紹 Neutron 的一些概念和名詞。 Neutron 概念 Neutron 提供使用者創建網路跟其子網域，並可將其他 OpenStack 服務（如 Compute）將虛擬設備連接到這些網路上的端口，通常最常見的就是連接 Instance 到網路。Neutron 支援每個 project 擁有多個私有網絡，並允許 project 選擇自己的 IP addressing 方案，並且不同網路中的 IP 地址與其他 project 使用的 IP 地址重疊。 有兩種類型的網絡，provider network 和 self-service network，這些網路是可以在 project 之間共享的。 Provider Networks Provider networks 為實例 (Instance) 提供 L2 網路連結，並支援 DHCP 和元數據 (metadata) 服務。 這些網路是連接到資料中心現有的 L2 網路，通常使用 VLAN (802.1q) tagging 來識別和隔離它們。
- [從裸機到雲端：OpenStack Neutron 介紹 1](https://igene.tw/openstack-neutron-intro-1) - 昨天為讀者介紹目前 OpenStack 中算是最核心的元件，Keystone，今天來介紹 OpenStack 筆者認為最複雜的原件，Neutron，也是 OpenStack 提供網路服務的元件。 Neutron 架構 OpenStack Networking (neutron) 允許您創建網路介面 (network interface) 並接上其他 OpenStack 元件管理的服務 (如 Nova VM)，使其能夠連接到網絡。可以透過不同的後端 plugin 去因應不同的網絡設備和軟體，為 OpenStack 架構和部署提供靈活性。 它包括以下組件： Neutron-server 接受 API 請求並將其路由到適當的 OpenStack Networking 插件以進行操作。 OpenStack Networking 後端 plug-ins 和 agents 插入和拔除端口，創建網絡或子網路，並提供 IP 位置。這些 plug-ins 和 agents 根據不同的雲中使用的供應商和技術而異。常見的 plug-ins 為 OVS, Linux Bridge 和 OVN，後續會介紹其架構。 常見的 agents
- [從裸機到雲端：OpenStack Keystone 介紹](https://igene.tw/openstack-keystone-intro) - 上一篇介紹了歷史最悠久的 OpenStack 元件 Nova，這篇要來介紹目前 OpenStack 中算是最核心的元件，Keystone Keystone 是什麼？ 官方文件中是這樣敘述的： Keystone 是一個 OpenStack 服務，通過實現 OpenStack 的 Identity API 來提供 API 客戶端認證、服務發現 (service discovery) 和分散式多租戶授權 (distributed multi-tenant authorization)。 簡單來講，你可以把它當成 OpenStack 中的認證服務，並且記錄了所有 OpenStack API 的所在位置 (endpoint)。 Keystone 架構 Keystone 是由多個不同的內部服務 (internal service) 組成，而這些服務通常是組合在一起使用。例如：一個認證的請求首先會透過 Identity 服務驗證使用者提供的 credentials，成功後透過 Token 服務生成一個 token 給使用者。 Keystone 包含了以下服務： Identity Resource Assignment Token Catalog 我們將一一介紹這些服務的功能。
- [從裸機到雲端：OpenStack Nova 介紹 2](https://igene.tw/openstack-nova-intro-2) - 上一篇文章我們介紹了 Nova 的功能與其使用方法，本篇文章將會繼續介紹 Nova 的架構 OpenStack Nova 系統架構 Nova 包含多個伺服器進程 (process)，每個進程執行不同的功能。 面向用戶的界面是 REST API，而內部 Nova 的不同元件透過 RPC 來進行溝通運作。 API 服務器處理 REST 請求，這通常涉及資料庫讀/寫、或是 RPC 消息發送到其他 Nova 服務，並生對應的 REST 回應 (response)。 RPC message 傳遞是通過 oslo.messaging 完成的，它是一個 OpenStack 元件共用的 RPC message 抽象層，讓 OpenStack 元件可以不用在意底下 RPC 的實作。 大多數主要的 nova 元件都可以在多台伺服器上運行，並且有一個 manager 來監聽 RPC message，達到高可用性和附載平衡的目的。一個主要的例外是 nova-compute，它只在每一個其管理的 hypervisor 上運行單一個進程（使用 VMware 或
- [從裸機到雲端：高層架構介紹](https://igene.tw/from-baremetal-to-cloud-4) - 我們在前幾篇文章介紹了 NIST 對雲端的定義，從今天開始文章將會進入正題，教你一步一步從裸機蓋出雲端。首先我將會大致介紹一下筆者預計蓋出雲端的架構。 IaaS Layer 本次雲端的 IaaS Layer 將會使用 OpenStack 來提供服務，選擇的原因如下： 目前最常見的私有雲都是使用 OpenStack 發展成熟，使用者多，規模小到大皆有 Open Source Open Source Open Source Open source 最為重要所以列了三次。由於是 open source，軟體將容易取得並且免費使用 (Apache License)。讀者們能夠容易地跟著筆者腳步實作。 PaaS Layer PaaS Layer 將會選擇 Kubernetes 來提供服務，選擇的原因如下： 目前最常見的 container orcherstration 平台 各大公有雲都有提供 managed service 基本功能發展成熟，使用者多，規模從小到大都有 Open Source Open Source Open Source 相信很多讀者應該皆有 Kubernetes 的經驗，本次主題也會有教學如何將 Kubernetes 架設在 OpenStack 上並且使用
- [從裸機到雲端：雲端定義 3](https://igene.tw/from-baremetal-to-cloud-3) - 昨天我們介紹了雲端的三種服務模式，今天要接續昨天的雲端定義，來介紹雲端服務的三種部屬模式。 部屬模式 NIST 所定義的雲端的部屬模式主要以下這幾種 私有雲 (Private Cloud) 公有雲 (Public Cloud) 混合雲 (Hybrid Cloud) 社群雲 (Community Cloud) 有些人也會將混合雲稱之為多雲 (Multi Cloud) 在這裡的介紹同樣會引用部分中興大學樂齡學習網的翻譯 私有雲 雲基礎設施專為組織而運作，這可能是由組織本身或第三方管理者就地部署(On premise)或遠端部署(Off premise)。其中，私有雲除具備公用雲環境的彈性優點，還能因網路與使用者受到特殊限制，且資料與程序皆在組織內部管理，較不受網路頻寬、安全疑慮、與法規限制等影響，讓雲端供應者及使用者更能掌控雲端基礎架構並改善安全與彈性。 簡單來講，公司自己建置的雲端通常都會是私有雲，使用者通常為公司內部其他開方部門。 社群雲 雲基礎設施由眾多利益相仿的組織掌控及使用，社群成員可共同使用雲端資料及應用程式，他們擁有共同的關注問題，例如特定任務、安全要求、政策和合規性考量等。可能由組織或第三方管理，且可以就地部署與遠端部署。 此種模式目前應該比較少見。 公用雲 雲基礎設施提供給一般大眾或一個大產業集團，由銷售雲服務的組織所擁有，除彈性之外，又能具備成本效益。這讓公有雲使用者可以省下管理實體機器以及其機房、電力、散熱設施的成本以及技術。另外「公用」並不表示使用者資料可供任何人查看，雲供應者通常會對使用者實施使用存取控制機制。 公有雲也是大眾最為廣泛認知的雲端。目前國際上公有雲三大業者為 AWS, Google GCP, Microsoft Azure，另有其他比較小規模的如 Oracle Cloud, Tencent, Alibaba, IBM Cloud 等等業者。 混合雲 雲基礎設施是由兩個或兩個以上組成的雲(私有、社群或公用)，此種雲維持單一實體，但是藉由標準或專有技術聯繫在一起，使資料和應用程序具可移植性。 此類這個模式中，使用者通常將非企業關鍵資訊外包，並在公用雲上處理，但同時掌控企業內部機敏服務及資料。 現在有些廠商為了避免將雞蛋放在同一個籃子裡，也開始規劃同時使用多個公有雲，避免因單一公有雲發生問題而造成服務中斷。 通常要架設混合雲會需要工程師對各個雲端有一定了解，並且混合雲比較難使用個公有雲獨有服務，因為需要程式在各個不同雲端都能正常運作。 以上為 NIST 定義的四種雲端部屬模式。 小結 雲端部屬模式應該同樣相較於必要條件來的易懂，相信很多讀者應該也有使用公有雲的經驗。 本次鐵人賽將會專注於私有雲的概念，帶領大家一步一步從一台實體的 server
- [從裸機到雲端：雲端定義 2](https://igene.tw/from-baremetal-to-cloud-2) - 昨天我們介紹了雲端的五個必要條件，今天要接續昨天的雲端定義，來介紹雲端服務的三種服務模式。 服務模式 雲端的服務模式主要分為三種 基礎設施即服務 (Infrastructure as a Service) 平台即服務 (Platform as a Service) 軟體即服務 (Software as a Service) 我們會在接下來的介紹簡稱為 IaaS, PaaS, SaaS。我會在這邊引用中興大學樂齡學習網的翻譯 IaaS 「基礎架構即服務」，是虛擬化後的硬體資源和相關管理功能的集合，透過虛擬化技術將運算、儲存和網路等資源抽象化，實現內部流程自動化和資源管理優化，進而向外部提供動態、靈活的基礎架構服務。此層的消費者使用處理能力、儲存空間、網路元件或中介軟體等「基礎運算資源」，還能掌控作業系統、儲存空間、已部署的應用程式及防火牆、負載平衡器等，但並不掌控雲端的底層架構，而是直接享用IaaS帶來的便利服務。 以各大雲端服務商為例，下列服務都是 IaaS 的範疇 AWS: EC2, VPC GCP: GCE Azure: VM, Block Storage PaaS 「平台即服務」，是為雲端應用提供了開發、運行、管理和監控的環境，可說是優化的「雲端中介軟體」，優良的平台層設計可滿足雲端在擴充性、可用性和安全性等方面的要求。此層的消費者可透過平台供應商提供的程式開發工具來將自身應用建構於雲端架構之上，雖能掌控運作應用程式的環境（也擁有主機部分掌控權），但並不掌控作業系統、硬體或運作的網絡基礎架構。 各位很常聽見的 Kubernetes 大致上即被歸類在 PaaS (Container as a Service)，各種 managed service 如 database 等等也是。 以各大雲端服務商為例，下列服務都是 PaaS 的範疇 AWS:
- [從裸機到雲端：雲端定義 1](https://igene.tw/from-baremetal-to-cloud-1) - 前言 大家好，我是 Gene，如果有參與過 Cloud Native Taiwan User Group 的朋友應該都有聽過我。本次被社群成員推坑第一次來參加鐵人賽，將以 從裸機到雲端 -- 30 天教你蓋雲端 為題目。 本次參賽將會從雲端的概念開始介紹，一路帶讀者從雲端的概念開始認識，接這進入到 OpenStack 的架構及部屬方式，最後帶到 Kubernetes 的架構並且如何在 OpenStack 上部屬 Kuberentes 整體來說，本次主題將會帶學員從簡單的 Linux 機器一步一步操作自己建立一個私有雲。 雲端定義 通常雲端的定義都會依據 The NIST Definition of Cloud Computing 來解釋 NIST 將雲端的定義分為三種不同方向做定義，分別為： 必要特性 (Essential Characteristics) 服務模式 (Service Model) 部屬模式 (Deployment Model) 必要特性 雲端的必要特性總共有五種，也是雲端的最核心概念。其中包含了: 隨需求應變自助服務 (On-demand Self-service) 消費者可以根據自身需求，而不需要藉由跟廠商的人為互動即可依自身需求去使用雲端服務商所提供的網路、儲存和運算資源。 廣泛的網路 (Broad Network Access)
- [利用 Ceph-Ansible 部署 Ceph Cluster](https://igene.tw/ceph-ansible-deploy) - Ceph 是一個 open source 的分散式儲存系統，能夠同時提供物件、區塊跟檔案系統的儲存，所以被大量使用在 OpenStack 部署中。本篇文章將介紹如何透過 Ceph-Ansible 去部署一個 Production Ready, High-availability 的 Ceph Cluster。
- [Container vs VM: When and Why?](https://igene.tw/container-vs-vm) - Container 跟 Virtual Machine 的使用時機在網路上已經被討論了很久。每個人都有自己的看法和意見，有些人支持純 Container，有些支持純 VM，也有些支持 Container on VM。本篇文章將以個人看法針對 Container vs VM 做介紹跟其適用的使用時機做論述。
- [OpenStack nova-scheduler 是如何運作的](https://igene.tw/how-openstack-nova-scheduler-works) - 最近在工作上因為某些緣由看了很多關於 nova 的 code，因而打算來寫一些文章記錄一下 nova 是如何運作的。首先第一篇將由 nova-scheduler 的部分開始。會帶讀者從 code level 了解 conductor 如何 call scheduler 到 scheduler 怎麼做決定流程。
- [軟體工程師的 Work From Home 環境](https://igene.tw/engineer-home-office) - 最近因為疫情關係越來越多公司採取在家工作的形式，本人服務的日本 LINE 也從 2 月底開始就在家工作了。也因為如此，為了讓自己有一個良好的工作環境也陸續購入了許多設備來增進自己在家工作的效率。這篇文章將會介紹筆者在家工作的一些設備已使用經驗等等，給因為各種原因要在家工作的讀者參考。
- [Stax SR-009BK/SRM-727A 開箱](https://igene.tw/stax-sr-009bk-srm-727a-unboxing) - 身為一個軟體工程師在 coding 時怎麼可以沒有一副好耳機呢？於是就有了這篇跟技術毫無關係的 Stax 限量 180 隻 SR-009BK 跟靜電耳機擴大器 SRM-727A 的開箱文。
- [日本 LINE 工作三個月心得](https://igene.tw/working-at-line-3-months) - 各種因緣際會下， 2019 年年底來到日本，2020 一月入社後，也要在日本領第三份薪水了。從大學畢業後一路當兵又進來當新卒，很久沒有寫文章了。趁最近因為疫情關係 Work From Home，空閒時間比較多，來記錄一下第一份也是第一次來國外工作的心得。
- [LINE Tokyo 面試心得](https://igene.tw/line-tokyo-interview) - 因緣際會之下在社群朋友的介紹下得知 LINE 有在找 Private Cloud 的 Infrastructure Developer Engineer。目前已經面試完畢並且拿到 offer，決定來寫一篇介紹一下 LINE 面試過程以及一些心得給有興趣加入 LINE 的人參考。
- [RDMA over Commodity Ethernet at Scale – 論文導讀](https://igene.tw/rdma-over-commodity-ethernet-at-scale-overview) - 在上一篇文章 RDMA Overview 中簡單了介紹了一下 RDMA 這個技術，這次將為 Microsoft 在 2016 年 SIGCOMM 發表關於他們資料中心大規模應用 RDMA 所撰寫的論文 RDMA over Commodity Ethernet at Scale 做簡單的導讀。
- [Calico 基本架構介紹](https://igene.tw/calico-architecture) - Calico 是一個純 L3 的 Datacenter 網路方案，跟 Kubernetes, OpenStack 都有非常好的整合，也是 Kubernetes 常用的 CNI 之一。本篇文章將會介紹 Calico 基本元件以及架構。

## Categories

- [OpenStack](https://igene.tw/category/cloud/openstack)
- [Ceph](https://igene.tw/category/storage/ceph)
- [Cloud](https://igene.tw/category/cloud)
- [Container](https://igene.tw/category/container)
- [Network](https://igene.tw/category/network)
- [Storage](https://igene.tw/category/storage)
- [Misc](https://igene.tw/category/misc)
- [Kubernetes](https://igene.tw/category/container/kubernetes)
- [Linux](https://igene.tw/category/linux)

## Tags

- [OpenStack](https://igene.tw/tag/openstack)
- [Kolla](https://igene.tw/tag/kolla)
- [IaaS](https://igene.tw/tag/iaas)
- [Kolla-Ansible](https://igene.tw/tag/kolla-ansible)
- [Ansible](https://igene.tw/tag/ansible)
- [Ceph](https://igene.tw/tag/ceph)
- [Ceph-Ansible](https://igene.tw/tag/ceph-ansible)
- [Container](https://igene.tw/tag/container)
- [VM](https://igene.tw/tag/vm)
- [Kata Container](https://igene.tw/tag/kata-container)
- [Best Practice](https://igene.tw/tag/best-practice)
- [Podman](https://igene.tw/tag/podman)
- [LINE](https://igene.tw/tag/line)
- [面試](https://igene.tw/tag/面試)
- [RDMA](https://igene.tw/tag/rdma)
- [RoCE](https://igene.tw/tag/roce)
- [iWARP](https://igene.tw/tag/iwarp)
- [Microsoft](https://igene.tw/tag/microsoft)
- [Datacenter](https://igene.tw/tag/datacenter)
- [Network](https://igene.tw/tag/network)
- [calico](https://igene.tw/tag/calico)
- [bgp](https://igene.tw/tag/bgp)
- [Japan](https://igene.tw/tag/japan)
- [Infrastructure](https://igene.tw/tag/infrastructure)
- [Engineer](https://igene.tw/tag/engineer)
- [Stax](https://igene.tw/tag/stax)
- [耳機](https://igene.tw/tag/耳機)
- [靜電](https://igene.tw/tag/靜電)
- [WFH](https://igene.tw/tag/wfh)
- [在家工作](https://igene.tw/tag/在家工作)
- [KubeVirt](https://igene.tw/tag/kubevirt)
- [Kubernetes](https://igene.tw/tag/kubernetes)
- [nova](https://igene.tw/tag/nova)
- [scheduler](https://igene.tw/tag/scheduler)
- [vGPU](https://igene.tw/tag/vgpu)
- [Nvidia](https://igene.tw/tag/nvidia)
- [ProxmoxVE](https://igene.tw/tag/proxmoxve)
- [PVE](https://igene.tw/tag/pve)
- [ingress](https://igene.tw/tag/ingress)
- [nginx](https://igene.tw/tag/nginx)
- [FOSDEM](https://igene.tw/tag/fosdem)
- [FOSDEM23](https://igene.tw/tag/fosdem23)
- [cluster-api](https://igene.tw/tag/cluster-api)
- [k8s](https://igene.tw/tag/k8s)
- [ROCm](https://igene.tw/tag/rocm)
- [AMD](https://igene.tw/tag/amd)
- [GPU](https://igene.tw/tag/gpu)
- [ML](https://igene.tw/tag/ml)
- [SSD](https://igene.tw/tag/ssd)
- [kops](https://igene.tw/tag/kops)
- [psi](https://igene.tw/tag/psi)
- [linux](https://igene.tw/tag/linux)
- [pressure stall information](https://igene.tw/tag/pressure-stall-information)
- [llm](https://igene.tw/tag/llm)
- [chatbot](https://igene.tw/tag/chatbot)
- [tesla](https://igene.tw/tag/tesla)
- [3dmark](https://igene.tw/tag/3dmark)