大家好啊我們今天要講的是Longhorn這主題我是David Cole, Senior Manager,防術者這位是我是吳碩,也是Longhorn Project's Senior Manager很高興第一次來到這邊我們主要探討一下Longhorn,Longhorn是什麼講一下Longhorn的架構,Romap還有一些Update,Status Update這就是我們的Agenda所以就像我剛剛講的,我介紹一下Longhorn然後它的Momentum,現在的MomentumCommunity Status那主要的Feature SetRomap還有最近的Release那在我們比較深入一點去探討Architecture的部分盡量簡化,但是就是著重在重點這樣子然後一些重要的FeaturePerformance Benchmark那Longhorn是什麼呢,可能大家有用過可能有用過Longhorn,或者不知道Longhorn的話Longhorn其實很單純它就是一個底層的Infra的搜尋是Fundamental的,主要是Full分散式Broad Storage for Kubernetes但是它不只Broad Storage它可以Probide不同Type of Barlin待會我會介紹那它提供的Barlin呢它絕對是Highly Available因為它Based on Replication這裡是Longhorn主要的Fundamental的特色再來它不只基本的Volume的Operation它還Support Snashout Backup主要是Full in Cluster Snashout跟Out of Cluster Backup所以你可以想像你的應用的Scenario可以跨Cluster這就是我下面講的Cross Cluster Disaster Recovery一般的User在用的時候它絕對不會只是想當下的Cluster因為可能會有意外發生所以通常你需要搭配一個搜尋但是Longhorn其實把這所有搜尋都整合在一起所以你不需要再找Support Equation再來就是Playful Agnostic因為Longhorn Design就是Connected Based on Kubernetes所以所有Certified Kubernetes基本上都可以讓Longhorn不論你在哪裡Unprint, Cloud, Public Cloud都可以我們內部其實也有很多Dalys的Testing在不同的平台不論Unprint跟Public Cloud這就是現在的一些運作方式當然Longhorn它就是Open Source它現在是Incubating Project我們也是試著往Graduation走但是也需要更多的Community的支持Longhorn Design Principle其實非常Straight for all第一個就是Reliability因為我們要make sure data is consistency所以Creative Consistency是必要的所以make sure你的資料可以寫到所有Downstream的RevacarLonghorn本身它以為了避免資料的流失當然Revacation是一個Performance也很重要所以Snayshot我們用Copy and Write的機制然後更reliable的話不只Incluster所以有Backup就我剛剛提到的Userability就是我們非常重視User的Experience這也提到非常Highlight的One-Click Installation其實就非常Hemchop或者我們也有第三方整合就是Ranger的Marketplace你可以安裝Even Role Manifest不同的Installation的方式還有非常Straight for all的UI如果有用過Longhorn的話你應該可以知道說Longhorn的UI非常單純單純當然功能也是很完整Maintain的部分除了Day 1之外Day 2也是非常重要所以我們試著去讓知道說User會遇到的一些狀況Receive的狀況我們要怎麼去Handle所以有一個要Highlight就是Upgrade基本上你在UpgradeLonghorn的時候你不需要去Interromp的Wallow所以你的Wallow還可以Continue Running因為我們SupportNon-Disrupted UpgradeOK我們講一下講講看Longhorn的Moment就是Compute Status其實Longhorn它是幾年的Project了你可以看這個曲線從一開始它Introduce的時候到現在的成長其實蠻穩健的在成長的Github的Popularity其實也一直在增加現在是More than 5,000 stars然後它不只Community User Use它其實還有很多Enterprise Adoption這邊就不細講但是不同的Area其實都有的Wallow我們其實有一個PublicMactress Collection現在Wallow的話大概有93K的No Installation那超過我記得是5000K的Cursor那這個資訊都是公開的有一個Mactress.Longhorn.io大家有興趣可以去看OK那成長的話當然就是很不穩健的在成長當中這樣OK Feature Set這主要是要給大家Highlight一下說Cattle主要Longhorn Focus在哪裡第一個當然就是Volume Support那著重在Volume TypeAccess TypeAccess More所以這裡提到Brawl VolumeFile Season Volume還有在1.6我們會推出這個Adjust Storage Volume它會是一個File VersionOK那CSI Protocol Support也是很完整的第三個就是Volume Capability因為剛剛提到Longhorn它是Snecia Base那不只這個我們還備上Trim Provision所以可以讓你在空間的使用這樣非常彈性那Expansion Trim這都是該有的方式都有那最重要的就是Live UpgradeOK那Longhorn Performance或許用過Longhorn的人都知道說Longhorn是基於Ice Garcia Stack那可能在Performance上面有一些考量因為Longhorn的Design是一種它考量各個面向所設計的所以我們稱它是V1的Data Engine但是在Longhorn 1.5我們推出了V2 Data Engine它是基於SPDK所以它的Performance上面是有很大的Improved那待會說等一下也會介紹一下Performance的部分用V1 Engine跟V2 Engine可以套用在你不同的使用場景那其他像Storage TopologyData ProtectionData Service或Data Reduction這個都是我們重要的一些Piler所以我們在設計Longhorn的時候都會去針對這幾個Piler去Design說到底要往哪個方向走那或者是Community User有feedback的話我們根據這幾個Piler去決定說我們要怎麼做那細節的話大家可以再參考我們的slideOK那Enrollment的話我比較講Shorten就是說現在基本上Longhorn的Release是非常Consistency每年會有兩次的Feature ReleaseOK那1.5已經Release在6月份那很多很多項目那我想要highlight的就是V2 Data Engine我剛剛提到它是基於SPDK Preview Version那Suppose正常的LiveVolume的Live Cycle那目前在1.5的Version只能SupposeLight Rebuilding但是這個會Change因為在年底我們會推出1.6那1.6的V2 Data Engine它會變成Beta Version那它為什麼改變呢它SupposeSneciaBakeup還有Snecia的Revert那Bakeup的Restore那還有Light的ReviewRebuilding所以它更接近比較完整的Volume的更接近了那1.7是我們的最終目標就是讓V2 Engine是可以是GA那待會Sore也會介紹一下V2的部分這樣子那再來highlight的就是1.6有一個Upgrade Store Volume這也是很多Feedback因為現在Longhorn它其實就是Bar Volume跟Fire System但是其實如果你看一下現在的應用場景很多都是Application LabelData ProcessingData Pipeline它們都需要仰賴外部的Upgrade Storage那User就要自己Build那非常Longhorn的Volume去Build那我們其實看到這個其實我們可以直接把它變成One LineOne Stop Service所以User在Create Volume之後其實它可以Create一個Volume Type是Upgrade Storage那對應的Endpoint或Credential都會Combined在一起所以User就可以直接用這個做Inclass的一個操作這樣子那Architecture的部分我這邊大概再講一下那Longhorn的Architecture其實它就Based on Kubernetes那它有兩個主要的Interface就是Longhorn的CSI跟Longhorn的UI那全部都透過Longhorn的API所以第一最上層就是Interface的部分CSI主要是為了解解Cubernetes那第二層你有看到Longhorn Manager就是Longhorn的核心的Control Plan所以所有Volume的Life Cycle都控制在Longhorn Manager那最下層你會看到EngineRapica可能有點confused其實Engine對應就是Volume那Rapica對應就是那個Volume的Data所以你看到一個Engine有很多Rapica其實有很多份的Data那這塊叫做什麼這就是Longhorn的Data Plan那V1跟V2主要就是在這邊實現所以Longhorn其實就3塊InterfaceControl PlanData PlanOK那這個如果是實際來看你包含了那個Volume的話其實就是一般你在Volume的時候你會Request the volume那Volume就會透過Couponetics那Longhorn有Couponetics CSI Driver就會知道說OK 我有一個Request那我要開Volume了那我就會透過Longhorn Manager去create對應的VolumeEngine跟Rapica那知道說它要分配到哪一個No哪一個Disk因為Longhorn本身在Longhorn Manager裡面有一個Rapica的Scheduling它會根據不同的Factor去決定說它要怎麼做所以以上大概是講一下說Longhorn的狀態然後Longhorn的基本的Architecture那接下來我們講一下重點核心的一些方向跟這個Performance的部分好說好謝謝David前面的介紹然後接下來我們來講一下Longhorn的一些Highlight或者是一些比較好的一些設計首先我們可能需要從最基礎的SnapShot以及IO的讀寫來看OK前面我們知道Longhorn是有Replication的然後我們是一個Rate 1的一種Replication也就是說每一個Rapica都是有都是有Full Copy of the Data所以說所以說我們這個SnapShot這裡面就是介紹的其實是某一個Rapica裡面的OKData是如何管理如何操作的首先右邊是我們就是用戶看到的最終的Volume裡面它的Content是什麼樣的左邊的話就是Rapica是如何管理SnapShot以及當前的這個所謂的Volume HeadOK這裡面這些每一個Blog它的Size都是4K的然後左邊這些什麼Volume Head以及後面會出現的SnapShot它本質上都是Linux的Spark File這也是我們為什麼說可以用SIM Provision這個來管理數據的一個理由然後假如說我們現在去寫數據現在會把數據寫到當前的Volume Head裡所以說數據在左邊是實際上是寫到Volume Head的這個File裡然後右邊用戶看來OK就是第二塊和第四塊寫入了數據接下來OK我們想創建一個SnapShot然後我們就可以通過一個非常短暫的一個Lock然後直接把之前的Volume Head改成SnapShotFile它本質還是Spark File只是它是說在我們Longer的Rapica看來它就變成止讀的File以後新的Data會寫到新的Volume Head裡去然後然後假如我們要往新的Volume Head繼續寫數據可以看到如果是空的我們直接寫如果是比如說第四塊之前是有數據的我們會有一個Copy on write的一個機制會把舊的數據讀出來然後基於舊的數據去改然後Append到新的Volume Head裡所以說我們這種操作就相當於類似一種Append only所以說基於這麼一種邏輯或者是這麼一套設計我們就可以構建出我們的核心的SnapShot Fisher以及IO的一個管理和操作然後接下來我們可以創建更多的SnapShot寫入更多的數據只要在右邊看來我們永遠是我們在右邊用戶看來或者是Application看來Volume Account永遠是讀比如說當前那個Index最新的一個數據比如說第三塊ok 第三塊第四塊我們看到SnapShot2裡是有最新的數據那我們就是顯示SnapShot2裡的數據就是基於類似的道理我們比如說後面又寫了一些數據在Volume Head裡現在現在Index3那個Block它現在最新的數據在Volume Head裡所以我們讀的話就變成了Volume Head裡的數據其他的也是類似的道理雖然說這邊可能會有一點點對所以說但是這個涉及到我們後面V2data engine的設計所以說這裡會花了比較多的時間來講解它然後我們的底力性也是就是追尋相反的原則就是說會把兩個SnapShot的合併起來比如說我們要removeSnapShot1我們先把data copy到你看這邊先把data從SnapShot2裡 copy到SnapShot1然後把它再把SnapShot2移掉然後再把SnapShot1這是我們SnapShot的一個最基本的操作其實這也是揭示了Longhorn是如何管理數據的這麼一個原理OK然後像SnapShot3的話它沒有辦法直接移掉因為它前面是Volume Head它是一個active的一個data file所以說我們不能直接刪掉那麼這時候我們就會直接就是說你看unmanned掉就是被覆蓋的那些舊的data然後把它標成一個removing的狀態就是表示它不能被revert這是我們基本的SnapShot的操作OK然後剛剛說每一個我們剛剛看到的視角是某一個SnapShot裡的某一個RabbitCard裡的SnapShot以及Volume Head的狀態然後這是實際的在比如說在某個工作節點上看到的具體的file是什麼樣子就是這樣的Dot image就是我們剛剛的SnapShot file前面最上面那個Volume Head就是所謂的Volume Head對這是具體的文件或者是RabbitCard的結構然後我們的backup也是類似的道理我們有了SnapShot有了這些data block我們會把它gathering到把它gathering起來然後上傳到遠端的這個secondary storage可以是s3可以是nlfs可以是cifs以及或者是arger block是大家選擇的可以是incluster也可以是out of cluster基於這麼一個道理就是我們也可以基於這麼一個設計我們可以很輕易的實現backup creation就是每個都是block只是block的size不太一樣而已對然後這個也是順便一提這個也是incremental的就是說我們先創建了基於SnapShot創建了一個backup後來基於SnapShot又創建了一個backup這兩個backup就是不會去重複的去備份之前就是已經上傳過的數據的你看這個地方SnapShotSnapShot3的backup它會重複使用之前的已經上傳的一些數據然後把新的數據再上傳上來大概就是這個樣子remove來就是相反就是完全沒有把這個backup本身給移掉然後它底下的data block如果沒有被引用的話也是直接拿掉的這個就是我們的backup機制這一塊可能會講得比較快因為原理都是原理都是差不多的因為都是基於SnapShot的這些這個block management來完成的所以說我們會簡單的跳過OK接下來我們講一下use case也是很多用戶也是很多用戶或者是customer比較關心的case比如說像在公有雲EBS volume裡面它可能它是沒有辦法去進行一個cross zone的一個migration的然後每個比如說EC2上它的EBS volume的可用數量是有限的所以說基於這麼一個限制有時候就會在EKS上會碰到這種問題比如說我們ZoomEA的這個節點掛掉第一個我們ZoomEB的pod它不能直接用ZoomEA的那個EBS volume這是第一個限制第二個限制是ZoomEA如果掛掉了我們也沒有辦法馬上就把相應的EBS volume遷移遷移到其他的Zoom裡進行一個快速的一個服務的一個恢復這是一個公有雲的一些簡單方案的一些比較簡單的或者是一些直接的方案的一些限制但是如果使用了我們ZoomEA的Volume事情就會變得不一樣了比如說假設還是這麼一個場景application在ZoomEA裡然後ZoomEA就會有一個相應的ZoomEA engine它會連接到各個地方的各個地方的replicar然後replicar本身是用底下的EBS進行數據存儲的假設假設假設ZoomEA掛掉了ZoomEA掛掉了那麼說我們可以在ZoomEB上興起一個engine然後連接剩餘的Healthy的replicar然後進行快速的一個服務的恢復這個是這個速度是非常快的因為因為engine是沒有狀態的是無狀態的所以說它也沒有存儲什麼數據它只是一個它只是一個process它可以很快的直接的連接其他就是整個classreplicationOK這是第一個UseCase第二個UseCase是我們基於backup和restore做的一個容災集群的一個案例首先我們有primary cluster我們會有些volume假設OK我們現在有設置了一個第三方的backup target這個時候我們可以設置一個quorum job來周期性的把primary cluster的volume數據給上傳到backup target去然後另外一方面我們有另一個就是容災的一個cluster它是現在是OK是沒有啟動的所以說但是我們可以先創建一個disaster recovery的volume然後這個是跟那個backup volume是做一個一一的一個man pin一旦我們primary cluster有新的數據寫入了然後會被quorum job備份到這個backup target去那個dr volume會去即時的去檢查這個backup target會把最新的數據給自動恢復回來假設這個時候我們有更多的volume可以創建更多的dr volume然後後續一旦primary cluster掛掉了我們可以立馬激活dr cluster 裡面的所有的volume然後進行快速的一個一個服務的恢復所以說這個是第二個比較經典的use caseOK接下來接下來是接下來最後的重點是v1 volume和v2 volume的介紹首先我們可以看一下這邊是v1 volume它其實是分三塊的綠色的部分是分兩到三塊的最上面的application和style system可以說是上層的應用是如何去使用longhorn volume這個是一般是說交給用戶決定的然後中間的綠色的部分從block device到isgati target這個時候可以說是我們longhorn volume的前端然後紅色的部分就是我們longhorn volume的後端像block deviceisgati就是相當於會把數據forward到我們的controller或者engine然後engine再去forward到各個replication裡去所以說這個是v1 volume的一個基本的iopass然後大家也會發現這邊有一些有一些延遲的一些統計可以發現在isgati和在controller到replication中間都有很大的延遲這個會導致我們longhornv1 volume的性能就是達不到那個native disk的水平所以說基於這些concern然後我們就在1.5推出了所謂的v2 volume它是基於spdk的可以看到這個地方frontline就直接換成了mmeoverfabric然後我們的後端也是直接全部換成了spdk的一些instance像raid-bdef作為engine像底下的logical volume一系列logical volume作為replicat其實本質上是跟之前差不多的它的數據的管理也是跟v1 volume差不多的然後接下來我們就詳細的介紹一下為什麼OK這個v2 volume是怎麼實現的這個是還是instance manager它之前是負責管v1 volume的engine或者是replicat現在也負責管v2 volume的engine和replicat首先我們在每個instance manager會起一個spdk server它負責去抽象管理engine或者replicat和這個弄上所有的engine和replicat但是這個engine和replicat本質上都是抽象它實際上你看通過下面的虛線它實際上是對應的svgtt裡的rate1bdef或者是一系列的logical volume基於這麼一個類似的一個結構或者一個manping我們就能很輕易的實現v2 volume的控制以及live cycle以及一些基本的功能至於說為什麼v2 volume的性能要原好v1 volume這個就跟svgtt的設計有關svgtt是一個poly model所以說它它能更快的它不是interrupt model所以說它會能更快更好的響應io然後能盡可能的利用我們的disk的performance當然也有代價代價就是說會消耗更多的cpu和resource所以說在未來的版本同時會提供v1和v2 volume給大家選擇v1 volume是會應用一些low spec的環境可能用戶不太需要高性能的volume然後它的本身note的resource是有限的cpu memory都是有限的所以說我們那個時候會推薦使用v1的volume相反如果你需要高性能的volume那麼說我們就推薦使用v2的volumeok其實我剛剛像我剛剛說的v2 volume的一切和v1 volume都是差不多的在refga層面我們之前說我們是snare票或者volume headspot file在v2 volume在svk里它就是logical volume be thatok在我們那裏面我們是spot file extend或者是spot file blocks在v2 volume或者在svk的時間裏它就是blopcluster或者是block所以說像snare票像bucket都是類似的engine 也是類似的道理我們我們v1的volume engine是一個processv2的話它就是一個read 1be that然後front end就是從Iscati變成了mme over fabric然後我們之前refga和engine之間的連接v1是一個我們house made的一個protocolv2的話就直接也換成了mme over fabric對通過這些就是protocol的protocol的切換以及以及依賴於spk的這種更先進的這種block的管理操作我們就可以實現更高性能的volumeok接下來我們看一下benchmarking這個是我們的測試用的機器可以看到CPU和RAM都是比較充足的然後我們用的是file作為測試kbenchok然後我們接下來也會重點測三個部分一個是iops一個是throughput一個是latency然後這邊是file的一些基本的或者最重要的參數寫在這裡首先我們看到iopsiops就相比於之前來說ok它的寫的性能特別是寫的性能就是整體得到2到4倍的提升像randomread也會提到了也會有2到3倍的提升然後這個地方by the way就是紅色的部分是svk的就是v2volume的黃色的部分是v1volume的所以說你看到這兩個性能差距還是比較大的特別是像v2volume它如果是single replica的話就是那個淺紅色的那個那個那個呈現你會看到它是非常接近我們的baseline也就是local passpervenom可以基本看作是local diskok這是iops非常多的提升像throughput的話這邊會相對好一些因為v1volume的throughput本身也是比較不錯的因為我們加了那麼多層主要還是latencylatency對iops的影響可能會更大一些ok這邊可以看到右邊也有一些統計就是像multipleread也是有30%到50%的提升的然後然後像然後然後因為我們是多副本同時所以說也可以看得到不論是v1還是v2volume它的它的獨的性能throughput是很是能輕易的超過latency diskok最後是我們的latency可以看到latency就是直接v2相比於v1直接降了一半或者是三分之二這個是非常非常大的一個improvement像也是像single replica它的latency就基本也接近於latency disk所以說我們可以很很自信的說v2volume它的性能是非常棒的是足夠自身我們下一代就是面對那種各行各業就是高性存儲的需求的ok接下來是一個demo就是這個時候是會演示一下我們1.6版本1.6版本bacal和resort的一個功能全部都是基於v2volume首先我們有一個基於v2volume的一個story class你看這個地方back end driver是v2的然後我們會創建一個新的podpvc以及後面的pv和volume對 這個volume創建的時候對應的會有一個longhorn volume出現然後我們可以在us上很清晰的看到ok這個volume已經創建了並且並且變成Healthy狀態了它是得到這個節點可以看得到這些信息的可能都算是收集得比較全面的接下來我們會往這裡面寫入一些數據通過這個volume通過這個pod往這個volume寫入一些數據比如說我們寫入了200兆的數據然後看一下ok文件是不是200兆是不是是不是ok的ok 確實沒有問題然後之後再計算一下它的check上因為等一下我們要教育一下比如說我們bacal之後我們稍後會做restore我們要看一下bacal和restort數據是不是完全一致的所以接下來寫入數據之後我們會創建一個bacalbacal我們這個地方就是用用我們的UI創建會比較直觀因為還可以看得到我們的progressok創建bacal之後會順便創建一個snapshot這邊有一個progressok 這個綠色的表示已經創建好了然後這是bacalvolume現在這個volume只有一個bacal就顯示在這裡了接下來我們回來我們既然有了bacal我們就可以restore一個新的volume出來然後來教育一下我們的bacal是不是正確的所以說這地方我們我們還是通過UI來restore一個volumerestore一個新的volume出來這個地方我們的bacal不是通用的所以說我們restorev1也是v2這地方就是給大家一個自由切換的一個選擇也是一個migration的一個選擇當然這地方我們引述v2的volume的一個restore所以說這個地方它會先自動一個attach把數據當到了下來然後再自動做detach然後這地方稍等一下就ok了這裡也會顯示我們的restore的一個progress所以說UI這邊顯示會比較直接ok這也是之前的一些也是restore出來的一些信息接下來我們有了restore我們要去檢查它所以說我們要為它創建一個pvpvc以一個pod因為我們是通過pod去看這個volume的數據是不是正確的所以說這個地方我們也是通過我們先通過pvpvc可以創建一個我們可以通過ui創建pvpvcsorry然後pod的話我們還是通過yaml file直接創建我們先看一下我先這地方準備了一個pod的一個pod的一個yaml它是可以用existentpvc的然後把這個pvc名字輸入進去可以看到這地方pvpvc已經在通過ui已經創建好接下來我們創建pod直接去使用這個volume或者直接使用這個pvc一旦有pod使用我們的volume會自動做attach就是根據根據這個application的所在的節點就自動的attach到對應的節點接下來就是attach成功之後我們可以進行數據的教驗我們看一下我們剛剛我們resort的volume是不是含有剛剛back up的這個volume裡的那個所謂的那個file所以這個地方我們重新做一下check上當然這個地方是針對resort出來的volume做一個check上然後我們再看一下我們之前我們之前那個originalvolume還沒有刪掉我們看一下這兩個的check上是不是一致的這個可以看到是基本一致的OK然後你會發現v1volume和v2volume它們的一個優勢的存純是一樣的這個是好事但是我們如何能證明我們這地方demo的是v2volume而不是v1volume對吧所以說這地方我們接下來會進去進我們剛剛提到的internet manager裡面看一下剛剛講的那些component是不是都在比如說any是不是對應red1bdef然後replicar是不是對應一系列的所謂的svklogicalvolumebdefOK這地方我們找到了對應internet manager我們直接進去看我們這地方有一個自己debug用的一個binary可以直接跟svk通信然後可以看到裡面的一些它所有的instance你看這地方它這個就是resort出來resort出來一個replicar的其中的一個snapshot它是一個logicalvolume這個就是resort出來resort volume有某一個replicar的volume head同理這個是original volume的某一個replicar的snapshot以及它的volume head對所以說這個地方可以說明就是說每一個logicalvolume都對應的replicar的其中的一個snapshot或者它的volume head就是跟我們v1volume的設計是幾乎一模一樣的然後rate的話也是我們這地方get一個raterate的話就是這個就對應了我們剛剛v1volume的engine process就是這地方你看到這個naming這地方就是engine就是resort volume的engine它有三個replicar就在這裡列出來了然後同理這是original volume它的engine它也有三個replicar這個是在easy manager或者在底層OK我們真正實現是什麼樣的那些sdpk componentsOK這個就是全部的demo了應該就OK謝謝今天的內容就講到這裡接下來是qa環節請問大家有什麼問題嗎就是我剛剛看到那個你們有一個就是兩個zone之間切換的那個過程我的問題是說就是我們經常會在這個數據訪問的時候需要有保證說我不能有兩端共同去寫對我在這樣切換的時候我怎麼樣有就你們有沒有什麼方式去保證說我zonee那邊肯定是結束了因為你有可能出現說那邊是down了但是你有可能兩邊互相之間出現惱劣的這種情況對吧那怎麼保證說就有沒有機制保證說那邊的寫已經完全結束不會再有寫了我這邊可以安全地去做一些Io還有一問題是那個多副本的這個情況下為什麼剛剛看到那個數據就lps和latency都會比單副本的情況下要差一點這就是有什麼原因嗎OKOK先解釋第一個第一個是說我們就是zonee可能節點失去聯繫了對吧不論是down掉了或者network down掉了或者network cutoff我們會先把之前的Volume給detach這個時候Angine和Rap那個Angine我們沒辦法管但是剩下的Rap我們可以把它給停下來停下來之後它跟之前Angine的Connecting就斷掉了這個停下來的過程是哪邊來確定的呢是longhorn來確定的我們longhorn manager對我們有說這個node變成node所以我們另外的機制就可以主導說我們可以說OK這個node的狀況我們讓我們讓這個Volume就disconnect過去但是這可能會有no partition的問題所以有另外一種default的機制就是讓couponet決定因為怕的failover是couponet決定怕failover所以Volume的detach也是couponet決定couponet決定所以當它決定之後我們才決定怎麼做OK所以就不會有不會有你剛剛講的問題OK那這整個切換的過程大概會有多長時間就看它怕什麼時候被eviction就是說如果那個depends on說你的couponet設定因為有default eviction我記得是五分鐘五分鐘但是longhorn其實有一個setting那個setting說如果你的環境你可以確保說腦裂的狀況你可以control的話就是說那個node那個condition是你可以in show的話longhorn有一個condition就是說當你的volume它是uninspected detach那uninspected detachlonghorn可以知道說它是walking上面有問題那它有一個設定就是說它可以主動去幫你把那個managed part砍掉讓它trigger這個volume detachment的behavior那longhorn就可以那個新的part就可以failover到新的node那直接起來OK 了解那它有這個grainure setting了解但bydefault是followcouponetic setting對那第二個問題是第二個問題是多副本的情況下為什麼比單副本的soup和lps和latency都要差一些對longhorn設計是一個多寫的我們為了保證cross consistency我們的每一個到engine的寫或者到longhorn back end的寫我們會等所有的rep card寫完我理解我說讀對random的這個讀和這個random讀的這個latency和lps像我剛剛說的我們中間加了很多layer不你相比單副本來說就是同樣的engine但相比單副本來說你的三副本都會比那個要差一些對 我們是round the ribbon的去讀所以它可能會讀到remote它沒有一默認情況下是沒有讀local的對目前是沒有 對現在是它是就是剛剛說講的它是round the ribbon但是soup就會比較高但是如果你是說lps的確它是但是我們其實有community有feedback這個問題說讀的時候可不可以先try local對那可能會get betterlps那這個其實Tiki有在討論對現在就這樣說其實讀的話我們有就是local rep card我們前面的ar down的一些layer也會帶來額外的latency所以說就是不論是單副本還是多副本就目前是v1不能是比不了就第二個問題ok喂你好我想請教一下就是目前這個longhorn它主要就是在原生存儲裡面說支撐的一些主要使用場景是什麼就是主要作弊的就是其實它就是近目前的這個研視和lps就是所能支撐的你們看到的就是所用起來的這些場景是哪些場景可以講講一般來講就是你當你是iO intensive application你當然會比較重視iO performance但是如果你的像我昨天聽到有一個case就說它其實不是很重視iO intensive它不是很重視那個iO intensive它反而重視是RE然後它會把資料讀到memory那這時候它可能就是說我輸不夠的話RE的輸不夠的話後面我的operation就不會仰賴continue的iO那這種狀況的話它可能就適合V1所以就是像剛剛我們講的V1 V2就Depend on說你對iO的依賴性或者它的強度如果你的application是一個比如說像現在很熱門的Machine Learning的Data Processing這種application的話你可能就很希望你的Volume的performance是高於高於V1的performance對所以就這個真的是Depend on你的使用情境或者是有些用戶它確實並沒有太強調iO的performance它更希望一個穩定的一個高可用的一個存儲場景然後他們的比如說它是一個to be的它本身也是個to be的用戶它可以使用我們它可以可以為每個它用戶的一個cluster構建一個slow resistance一個小而快的一個hybridle的一個solution這樣的話就是它它為每個用戶為每個客戶或者為每個用戶提供的都是一個小的cluster它不需要去設計dedicated storage它就是用這個cluster裡面自帶的disk它就可以完成它們最基本的要求這也是一個比較盡電的使用場景比如說它有幾百個cluster在管著OK每個cluster都需要一個store resistance就用long hold然後每個然後這裡面這個小cluster它的disk也是足夠它的application使用的對這種小短而快的一種所以基本上就兩個cluster因為你當你還沒有應用場景的話你就單純會看這些metrism如果你還沒有應用場景的話但是你有應用場景的話比如說iO intensity你看的東西就不一樣你看的可能是stabilitysoup但是它的快或慢可能是secondary所以這個depends但是long hold在這邊它就是因為position就是說它知道說long hold希望是一個general首選但是它又希望所以這就是為什麼我們現在正在開發v2的原因因為其實是蠻多feedback它來自於不論它是entry point user它單純就看metrism所以這個就不是場景它就是直接看那這個的話我們需要給這種user一個feedback所以說long hold其實可以達到那個境界但是如果根據不同場景的話它就可以根據它的需求去選擇它會用v1還是v2對那我說v2 volume肯定是需要更多的memory和cpu的resource像svk它是需要huge page的一個預留的所以說這個地方那比如說從目前就是這個有實際落地的場景你說v2嗎還是v1就是不論是v1是v2v2其實還在開發中v1的v1當然是有就是我剛剛在momentum那邊有介紹過它其實是有antibus我可以我不能講說哪些公司但是說我有huge的場景有finance的場景然後even還有solution provider的場景他們利用long hold當成一個他們整合的solutionprovide service給userend user那個這個半導體manufacturer都有所以這個但是重點重點其實產業別雖然重要但最重點還是你的applicationthe purpose這個更重要就是說你可以去覺得說你到底你追求的是說非常非常很快的IO還是even說穩定的輸入譜good enough然後你的環境是loseback那你可能就會選擇用v1對大概是這樣OK 謝謝好 那兩位老師好那我最後我就多問兩問題我們剛剛就是一個企業級的應用我們現在在用long hold為內部提供這個接合hub service的提供服務然後我們想因為我們有大量的hdd的資源所以我們想問一下long holdsd跟hdd的這種閃混的這個就是混布的這種場景我們是怎麼支持的對如果說我們還是推薦就是說對於單個volume來說它的replicat肯定是都是hdd或者sd這樣的話我們比較好區分這個區分方法就是說我們有tag通過你給hdd的disk加tag加hdd這麼一個tag加sd的話disk也加一個對應的tag然後你在創建volume的時候你可以選擇tag一個tag selector這樣的話就是說我可以你是需要高性能的就用那個對應的story class然後使用對應的tag去創建基於sd的volume反過來就是hdd然後接下來基於hdd它的latency可能會有一些出乎意料的高比如說就是io一旦密集的時候或者一瞬間有一個pick的時候還有比較高所以說基於這個我們在setting也可以說你可以適當的增加io time out我們在這兩個版本做了很多的適配適配工作對我們有這種比如說像其他的傳統的這種訊號或是傳統盒它使用sd給hdd作為緩存的這種機制對cache的這種機制目前沒有我們之前很嘗試過要做cache disk但是那個performance一開始的panelty太高它如果我們depend on你是right through還是就right back所以我們有做過一些測試但是那個時間點我覺得並不適合V1的現狀但是或許在V2我們可以去review這個機制因為V1它其實latency剛剛所有介紹它其實latency已經很多層當你在cache的話或許會好到後面的re但是你在前面的right那個suffering可能會比較重一點所以我覺得比較適合的話可能是在V2再去review明白那在對於企業級部署的話我們是建議比如直接部署在裸盤上還是先騎一層LVM然後在泡在上面泡對對dedicated disk是絕對需要的如果你是enterprise那LVM就是逐漸你的varnished space但是如果你有LVM的話也是蠻好因為你可以讓spec的運用會比較彈性一點因為有可能你可以增你會增加不同的more rape card在那個diskLVM就是可以擴充你的specic usage所以沒有強制但是dedicated disk是絕對必要的但是如果是比如說home labpercent usage或者是公司內部的就沒有這麼強制因為LVM其實就是我講它是一個general首先它可以讓你去調配說你要怎麼設計明白然後還有一個問題就是我們因為在結合的Havis剛才我們看V2的特性挺好的因為我們其實保受性能的困擾所以那能不能我不知道我們的LVM跟Havis的這個版本關聯性的後面是怎麼安排的因為Havis一般會結合一個LVM的版本比如說1.2會結合1.3.2那剛才比如說1.6 對那我們是是可以結合嗎還是會怎麼樣那待會也可以私下再聊如果我簡單講一下就是說Havis最的版本就是minus 1原則上就是先講這樣所以在下個版1.3的話它就會追上1.5那Longhong在V2 Engine的話目前是α就是我們叫preview那experimental beta會在1.6所以很可惜E3還不會但是我們就是會在review這個cadence因為實際上的確是有一個minus 1的狀況對所以可能看看之後1.3之後我說Havis1.3之後好的 謝謝謝謝好 謝謝好 謝謝大家謝謝大家