• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            runsisi

              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
              45 隨筆 :: 15 文章 :: 26 評論 :: 0 Trackbacks

            2019年3月3日 #

            https://runsisi.com/

            posted @ 2019-03-03 15:05 runsisi 閱讀(199) | 評論 (0)編輯 收藏

            2015年8月15日 #

            基于ceph RBDIscsi target實現分析

            runsisi AT hust.edu.cn

            2015/06/12

             

            本文總結基于ceph存儲后端的iSCSI target實現,針對幾種可能的實現思路進行分析,并輸出本文檔,本文內容組織結構如下:

            1. 描述本文的目的及內容;

            2. iSCSI使用ceph作為存儲后端的基本實現思路;

            3. 分別闡述幾種可能的實現方式,分析其各自的特點和可能存在的一些技術障礙;

            4. 最后簡單總結全文。

            1.        問題提出

            ceph作為一個真正意義上的統一存儲系統,有著很好的應用前景,但到目前為止有多種原因限制了其在傳統存儲應用領域真正大范圍的應用,如客戶端僅支持GNU/Linux系統,內核態客戶端實現也僅會合入高版本的內核中等。而對于iSCSI這種傳統的存儲應用而言,由于客戶端配置簡單且足夠通用,常見的各種系統(包括操作系統和應用系統)一般都對iSCSI有很好的支持,因此為了擴大ceph的應用范圍,特別是應對只支持iSCSI的系統,ceph必須通過某種途徑實現對iSCSI的支持。

            2.        基本思考方向

            ceph集群目前支持三種形式的存儲接口:文件、對象、塊,其中塊接口(RBD)SCSI塊設備讀寫所要求的接口一致,因此可以基于cephRBD提供SCSI存儲系統后端,當然如果有足夠信心的話也可以完全拋棄ceph提供的這三種基礎接口,而在原始的RADOS接口上開發新的塊接口,當然除非原始的RBD接口有重要缺陷,否則暫時還看不到重新發明輪子的必要,注意后文的討論都將基于這一基本假設。

            /Files/runsisi/基于ceph-RBD的iSCSI-target實現分析.pdf
            posted @ 2015-08-15 22:44 runsisi 閱讀(2463) | 評論 (0)編輯 收藏

            2015年8月2日 #

            1. virtualization

            虛擬化,與真實的、物理存在的對象相對應,用于隔離底層物理實現。其中計算機硬件虛擬化是我們所熟知的虛擬化技術,如使用VirtualBox等虛擬機軟件創建多臺x86虛擬機器,使用qemu模擬多種硬件平臺(x86PPC)等。其它常見類型的虛擬化技術包括:操作系統虛擬化(DockerFreeBSD jail),存儲虛擬化(pooling),應用軟件虛擬化(virtualenv)等[1]



            [1]本文只討論x86平臺的硬件虛擬化;


            /Files/runsisi/openstack學習.pdf

            posted @ 2015-08-02 22:38 runsisi 閱讀(390) | 評論 (0)編輯 收藏

            2015年1月30日 #

            runsisi AT hust

            http://www.shnenglu.com/runsisi


            [本文所提及的部署方法已不適用于新版的ceph-formula]
            本文簡單描述使用
            saltstack部署ceph集群(MON+OSD)的方法。

            1. saltstack基本概念

            mastersaltstack服務端,可執行程序為salt-master

            minionsaltstack客戶端,可執行程序為salt-minion

            grains:客戶端節點自身所固有的靜態數據,如節點的基本信息等;

            pillar:在服務端定義的、針對具體客戶端的數據。

            /Files/runsisi/salt-ceph.pdf

            posted @ 2015-01-30 19:46 runsisi 閱讀(1478) | 評論 (0)編輯 收藏

            2014年12月4日 #


            runsisi AT hust

            http://www.shnenglu.com/runsisi

            前言

            本文對使用puppet進行ceph集群的部署流程進行簡要總結。全文結構如下:第一、二節分別對puppetceph進行簡單介紹;第三節分析puppet-ceph模塊的結構和實現;第四節描述ceph集群部署的操作流程;第五節總結全文;附錄為參考文獻及代碼。

            1.     puppet

            puppet是一個開源的配置管理工具(Puppet is an open source configuration management utility[1]),同時也是當前最主流的配置管理自動化工具之一。

            Puppet有自己獨立的語言[2]用于編寫配置腳本,但不同于一般的腳本語言,該語言只描述被配置對象的狀態(即puppet中的資源),而不需要指定實現該配置所需要的操作步驟。puppet自身定義了很多常見的資源類型,但用戶也可以自定義資源類型,具體實現細節可以參閱“Puppet Types and Providers”一書。

            /Files/runsisi/puppet-ceph部署.pdf
            posted @ 2014-12-04 20:57 runsisi 閱讀(1857) | 評論 (0)編輯 收藏

            2014年9月10日 #


            runsisi AT hust

            http://www.shnenglu.com/runsisi

            前言

            CHAP認證是iSCSI協議中最主要的認證方式,現有的開源iSCSI實現(包括initiatortarget實現)基本上都只支持CHAP認證,本文將對CHAP認證及其在iSCSI協議中的應用作一個簡單的介紹。

            CHAP協議

            CHAP[1]的全稱是Challenge-Handshake Authentication Protocol,協議細節由RFC 1994進行定義。CHAP最初應用在Point to Point ProtocolPPP)中,用于實現PPP服務器對客戶端的身份認證,但也可以應用在其它需要對用戶或主機進行身份認證的場合,如iSCSI協議就規定使用iSCSI協議進行通信的設備必須(MUST)實現CHAP認證。

            注:附件中的壓縮包為iSCSI discovery會話的抓包信息,兩次抓包分別為單向CHAP認證和雙向CHAP認證過程,
            iSCSI normal會話的CHAP認證過程和discovery會話是一樣的,沒有再單獨抓包。

            /Files/runsisi/iSCSI_CHAP認證.pdf
            /Files/runsisi/iSCSI_CHAP_PCAP.7z

            posted @ 2014-09-10 22:25 runsisi 閱讀(2470) | 評論 (0)編輯 收藏

            2014年9月6日 #


            runsisi AT hust

            http://www.shnenglu.com/runsisi

             

            現在公司內部使用的RPM系發行版應該多數還停留在Centos6.xRHEL6.x版本,6.x系列的版本帶的vim好像都是7.2版本的,像我這種裝了spf13提供的vim插件包的TX就比較郁悶了,這個插件包只支持7.3及以上的版本,vim官方好像是沒有提供rpm包下載的,我每次都是自己下來源代碼進行編譯,其實挺不方便的,本來只需要進行一次的工作,每次硬是要重新編譯打包。讓我想起了在學校維護系里的網站時,需要添加一個生成本科畢業設計選題統計word文檔的功能,大概花了我兩天的時間才把這個功能給實現了,每次老師們想要生成這個文檔,就在頁面上點擊一下按鈕,然后稍等一小會,網站后臺會實時生成一個word文檔提供下載,好久之后我才突然開竅,其實只需要我自己生成一份然后掛到網站上就行了的,反正畢設選題每年只有一次,哪用SB似的每次都去查數據庫給生成一份:)

            googleGFW給屏蔽了,因此vim的代碼也取不下來了,只好從Centos7yum源里取了一份,路徑如下:

            http://vault.centos.org/7.0.1406/os/Source/SPackages/


            /Files/runsisi/centos6.x編譯打包vim7.4.pdf

            posted @ 2014-09-06 10:30 runsisi 閱讀(1762) | 評論 (0)編輯 收藏

            2014年9月3日 #


            runsisi AT hust

            http://www.shnenglu.com/runsisi

             

            1. 獲取源代碼

            獲取源代碼有多種途徑,其中ceph官方發布的源代碼路徑如下:

            http://ceph.com/download/

            在該路徑下下載相應發行版本的源代碼tar包即可,同時也可以使用git版本管理工具獲取最新的開發版本的源代碼[1]

            git clone --recursive https://github.com/ceph/ceph.git

            2. 建立編譯環境

            編譯打包ceph需要相應的工具鏈以及一系列的第三方庫,基于deb的發行版和基于rpm的發行版所需要的依賴并不盡相同,如果使用gitgithub獲取的源代碼,則在源代碼的根目錄有兩個文件:deps.deb.txt, deps.rpm.txt,這兩個文件分別記錄了這兩種類型的發行版建立編譯環境所需的工具及第三方依賴庫,但是這兩個文件所記錄的依賴關系并不一定完全準確,如果有缺失的依賴,編譯體系進行構建時會報錯,再安裝相應的依賴即可。

            /Files/runsisi/ceph_build.pdf

            posted @ 2014-09-03 22:02 runsisi 閱讀(2180) | 評論 (0)編輯 收藏

            2014年8月28日 #


            runsisi AT hust

            http://www.shnenglu.com/runsisi

             

            該錯誤在執行命令:ceph-deploy mon create-initial 時出現,說明該 monitor 節點曾經部署過 ceph 環境,該問題的解決方法很簡單,在執行該命令之前刪除該 monitor 節點 /etc/ceph/ 下的{cluster}.client.admin.keyring 文件(cluster名默認配置情況下是ceph)。

            該錯誤的具體原因待會解釋,先簡單介紹一下該命令執行過程中發生的事情:

            1. 啟動 monitor 節點的 ceph monitor 守護進程;

            2. monitor 節點執行 ceph-create-keys 命令;

            3. ceph-create-keys創建 {cluster}.client.admin.keyring

            4. ceph-create-keys創建 bootstrap-{osd, mds}/{cluster}.keyring

            5. ceph-deploy 所在運行節點從 monitor 節點取 {cluster}.client.admin.keyring, {cluster}.mon.keyring, bootstrap-{osd, mds}/{cluster}.keyring 到當前路徑;

            6. 以上任何一步如果文件已存在,則不會新建(或去 monitor 節點取)文件。

            回到我們遇到的錯誤,由于 monitor 節點之前可能使用 ceph-deploy 工具進行過部署,再次部署時沒有將 {cluster}.client.admin.keyring 原有的配置文件進行清理,因此第3步不會創建新的 keyring 文件,仍然使用上次部署使用的keyring,從而導致第4步操作會失敗,最終出錯。

            從上面的介紹,可以知道,如果要使用 ceph-deploy 工具再次對 ceph 集群進行部署,最好將各節點(包括 ceph-deploy 工具所在節點)上原有的配置文件清理之后再進行部署。

            /Files/runsisi/ceph_bootstrap_key_fail.pdf

            posted @ 2014-08-28 22:51 runsisi 閱讀(6621) | 評論 (0)編輯 收藏

            2014年8月21日 #

            http://www.cnbeta.com/articles/320875.htm

            竟然這么快。。
            posted @ 2014-08-21 00:34 runsisi 閱讀(17569) | 評論 (0)編輯 收藏

            僅列出標題  下一頁
            午夜不卡久久精品无码免费| 久久无码人妻精品一区二区三区| 93精91精品国产综合久久香蕉 | 伊人热热久久原色播放www| 久久精品亚洲精品国产色婷| 久久久久亚洲AV无码专区首JN| 国产精品欧美久久久久无广告| 亚洲精品国产成人99久久| 精品综合久久久久久97超人| 99久久成人国产精品免费 | 久久A级毛片免费观看| 久久久噜噜噜久久中文字幕色伊伊| 日韩中文久久| 性高湖久久久久久久久AAAAA| 人妻精品久久久久中文字幕| 久久久久97国产精华液好用吗| 精品久久久久中文字| 精品国产婷婷久久久| 久久精品国产只有精品66| 久久久久女教师免费一区| 色青青草原桃花久久综合| 国产aⅴ激情无码久久| 久久综合国产乱子伦精品免费| 99久久精品日本一区二区免费| 曰曰摸天天摸人人看久久久| 久久精品亚洲精品国产欧美| 99精品国产免费久久久久久下载| 无码人妻久久一区二区三区蜜桃| 欧美va久久久噜噜噜久久| 中文精品久久久久国产网址| 久久久久亚洲精品中文字幕| 一本色综合网久久| 国产免费久久精品丫丫| 欧美激情一区二区久久久| 72种姿势欧美久久久久大黄蕉| 国产精品成人99久久久久| 久久精品中文字幕一区| 精品国产一区二区三区久久| 超级碰碰碰碰97久久久久| 久久国产精品一区二区| 久久久久av无码免费网|