スポンサーサイト

  • 2014.12.03 Wednesday

一定期間更新がないため広告を表示しています

  • 0
    • -
    • -
    • -

    ぼくのCloudStackのおもいで

    • 2014.12.04 Thursday
    • 00:00
    くろです。
    はじめまして、こんにちは。

    皆さん、CloudStackにはどの程度関わられて来られたでしょうか。
    この記事では私が2013年3月からCloudStackに触れ始めて、
    自社内にプライベートクラウド環境を作り上げるまで、撃沈してきた思い出をさらっと書きます。

    ※ 比較的古いのであまり面白くもなく、実用価値も殆どありません。

    初めにCloudStackを触り初めたのが4.0.2でした。
    そこから 4.1.0 → 4.2.0 → 4.2.1 → 4.3.0 → (4.4.0) と環境に触れてきました。
    各バージョンを使用した環境ごとで苦しんだ思い出を淡々と書いていきます。

    では、よろしくお願いします。
     

    ■CloudStack4.0.2

    構成:KVM,FCストレージをCLVMと、SharedMountPint(中身はCLVM,GFS2)で構成

    ひと通り構成が完了した後に、様々な検証を進めていた環境です。


    CLVM構成でファイル書き込み検証

    CLVM構成上のインスタンス内ディスクで実行。
     
    # dd if=/dev/zero of=dummy bs=1M count=1000 oflag=sync
    1000+0 records in
    1000+0 records out
    1048576000 bytes (1.0 GB) copied, 5.76442 seconds, 182 MB/s
    ※複数同時dd実行では反比例してかなり遅くはなります。

    一台のインスタンスでの速度は中々の速度がでました。

    【補足】CLVM構成について
    CLVMはvolume group自体をcloudstackで管理する構成で、構築は比較的簡単です。
    ファイルシステムとしての共有の仕組みでは無いため大きなボトルネックはありません。
    ただし、インスタンス用ディスク領域がLV単位で作成されるため、
    容量の圧縮手法が無く、ストレージの容量を圧迫します。
    また、ファイル単体での管理では無いため運用時もそこそこの知識が必要になります。


    SharedMountPoint構成でファイル書き込み検証

    SharedMountPoint構成(CLVM&gfs2)上のインスタンス内ディスクで実行。
     
    # dd if=/dev/zero of=dummy bs=1M count=1000 oflag=sync
    1000+0 records in
    1000+0 records out
    1048576000 bytes (1.0 GB) copied, 19.3918 seconds, 54.1 MB/s

    gfs2のファイルシステムを使用する構成だと極端に速度が落ちました。

    【補足】SharedMountPoint構成について
    SharedMountPointはストレージ領域をCLVMとgfs2などで構成後、
    クラスターファイルシステムとしてパーティションをマウントさせ、
    OS上から扱えるファイル領域とし、cloudstackで管理します。
    インスタンス用ディスク領域はファイルとして扱うため、qcow2による圧縮手法が有効になります。
    ただし、gfs2によるファイルシステムのロック管理を行う?ためか、CLVMのLV毎の管理と比べ、IOが異常に遅い。

    CLVMでの構成は4.0.0から登場してきているようですが、選択肢としては速度重視である場合はCLVMとし、容量重視の場合はSharedMountPointになるのではないかと考え、併用して運用することにしました。


    ストレージアクセス不可問題発生

    テストではホスト機電源断からのインスタンスHAの動作まで確認が出来ましたが、検証を進めていく中で1台のホスト障害時にクラスタ内の全ホストがストレージにアクセス出来ない問題が発生。

     → クラスタ管理のCongaとCLVMの動作が危うすぎて、問題発生時の影響が大きくこれでは運用出来ないと断念しました。

     

    ■CloudStack 4.1.0

    構成:XenServer 6.0.2,FCストレージをPreSetupで構成

    KVMによるOSSを使用した自前のクラスタ構成は障害時にかなり厳しい現実を突きつけられたことから、XenServerを選択してみることにしました。
    何よりストレージの構成が非常に簡単。XenCenter超便利。Citrixさまさま。
    尚、プライマリストレージにNFSを使えればもう少し方向性が変わっていたかもしれませんが、既に機材があった為選択の余地はありませんでした。


    Windowsサーバハングアップ

    Windowsサーバインスタンスを構築しても数時間経過するとハングアップする現象が多発。

     → 暫く原因模索を行いましたが、明確な解決策に行き着かず、CloudStack4.2.0が登場してきたのでXenServer6.2とセットで選択することにしました。

     

    ■CloudStack 4.2.0

    構成:XenServer6.2,FCストレージをPreSetupで構成

    XenServer6.2が無償版としてリリースされ、CloudStackもそれに合わせた対応バージョンが出てきたので、選択。
    Windowsがハングアップする症状は発生しなくなり、この構成で「決まり」と思っていました。


    PreSetupのSR構成でファイル書き込み検証

    SR上のインスタンス内ディスクで実行
     
    # dd if=/dev/zero of=dummy bs=1M count=1000 oflag=sync
    1000+0 records in
    1000+0 records out
    1048576000 bytes (1.0 GB) copied, 9.85037 s, 106 MB/s

    KVMと比べ中間的な速度でした。


    インスタンスHAが機能しない

    過去に成功していたインスタンスHAが機能しない現象発覚。

    【バグ情報】https://issues.apache.org/jira/browse/CLOUDSTACK-4627

     → CloudStack 4.2.1でFixされている為、自分でビルドして使うことにしました。

     

    ■CloudStack 4.2.1-SNAPSHOT(2013/10/20付)※社内リリース1号

    構成:XenServer6.2,FCストレージをPreSetupで構成

    OSハングアップが発生しない事やインスタンスHAが機能する事でようやくまともに使える環境に。
    この環境は終息方向に向かっています。


    仮想ルータのHAProxyの停止

    一つの仮想ルータでロードバランサの機能を担うHAProxyのサービスが原因不明で停止しました。
    サービスの停止検知と自動復旧の仕組みも考慮しましたが、根本解決にはならないということで却下。

     → 仮想ルータでは本番環境には適さないとの判断しました。

     

    ■CloudStack 4.2.1※社内リリース2号

    構成:XenServer6.2,FCストレージをPreSetupで構成
       + SharedNWとFW,LBアプライアンス

    仮想ルータを使用せずにアプライアンス機器を使用する構成としました。
    アプライアンスはCloudStackとの連携はさせない構成で暫定リリース。
    利用者サイドでネットワーク周りを構成できないので、運用コストが下がらないのが難。
    この環境は現行稼働中です。


    APIでタグリストを一覧すると指定以外のリソースも表示される

    【バグ情報】https://issues.apache.org/jira/browse/CLOUDSTACK-7362

     → 諦めました。取ってきたデータを整形するなどで回避。


    VMスナップショットを取得時にエラーになる

    Revert VM: i-9-301-VM to snapshot: i-9-301-VM_VS_20140109091127 failed

     → 不安定であるため、機能を使用しないことにしました。


    XenServerで/tmp内の一部のファイルが肥大化する

    XenServer のホストでは「logrotate.conf」は使用されていない模様。
    使用されていると思われるコンフィグ「/etc/logrotate-xenserver.conf」にローテーション内容を追記し、とりあえずの対策としました。


    一部のインスタンスではライブマイグレーションが5割の確率で失敗し、停止する

    物理サーバやesxi上で稼働していたサーバをP2V、V2Vによってディスクイメージに変換して、テンプレート化し、CloudStack内にデプロイして稼働させました。
    同手法で取り込んだ環境のみライブマイグレーション実行時に失敗し、インスタンスが停止してしまう症状が発生。

     → 柔軟なメンテナンスが出来なくなったが、必要に応じて利用者に案内しつつ対応することとしました。

     

    ■CloudStack 4.3.0 ※社内リリース3号

    構成:XenServer6.2,FCストレージ、iSCSIをPreSetupで構成
    + SharedNWとFW,LBアプライアンス
    + 10Gのスイッチも採用
    + 仮想ルータもモニタリングがついたので使える様に

    現行最新環境として稼働中です。

    CloudStackとアプライアンス機器の連携

    アプライアンス機器をCloudStackとの連携させて使用する手法を様々なベンダーさんのお力をお借りして検証しました。

     → 結果として、運用に困らずに使えるほど作りこまれていないところが多く、断念しました。



    10Gネットワークの速度がFTP等による実測値で1.2Gbps程度しか出ない。

    Dom0、DomUにかかわらず、Xen環境上での最大速度は1.2Gbps程度となってしまう。
    ただし、同一ホスト上に10台程度並べて同時にIO負荷を掛けた場合、10Gbpsに近い速度がでるので仕様と判断しました。


    cloud_usageのデータが取れていない

    cloudstack-usage のサービスは正常に稼働し、プロセスも存在するが、usageのDBにデータが格納されず、
    サービス起動時にも下記のWARNINGが発生している。
     
    2014-09-10 08:17:39,684 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-2:ctx-eabc4c42) checking health of usage server
    2014-09-10 08:17:39,685 DEBUG [c.c.h.HighAvailabilityManagerImpl] (HA-2:ctx-eabc4c42) usage server running? false, heartbeat: null
    2014-09-10 08:17:39,685 WARN [o.a.c.alerts] (HA-2:ctx-eabc4c42) alertType:: 13 // dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: No usage server process running

    下記のリンクを貼る作業を行った所、正常にusageのDBにデータが格納されるようになりました。
     
    # ln -s /usr/share/java/mysql-connector-java.jar /usr/share/cloudstack-usage/lib/mysql-connector-java.jar

     → CloudStackユーザ会で著名な、きりん様のサポートのお陰です。感謝!


    rootディスクのマイグレーション
     
    • iscsi←→FCの停止ディスク移行(別のプライマリストレージへのインスタンス移行)は成功した。ただし、Nameが「ROOT-xx」から実行するたびに「cloud-<ハッシュ値>」と言う名称に変わってしまう。
    • iscsi←→FCのブロックマイグレーションは、異なる種類ストレージへは「Not Suitable」となっているが、実際は活用可能。(動くことは確認できた)
    • ブロックマイグレーションではNameも変わること無く、オンライン/オフラインで移行も可能。


    ライブマイグレーションボタンが反応しない

    一部のインスタンスにてライブマイグレーションボタンを押しても移行先ホストのダイアログがポップしない。
    同症状のインスタンスはホストをメンテナンスモードに変更しても移行されない。

    【バグ情報】https://issues.apache.org/jira/browse/CLOUDSTACK-6099
    【バグ情報】https://issues.apache.org/jira/browse/CLOUDSTACK-5660
    【バグ情報】https://issues.apache.org/jira/browse/CLOUDSTACK-7839

     → 暫定対処として、移行できないインスタンスを 停止 → 起動 を行った直後であれば、移行できるようになることを確認。
       ※再起動では改善されない模様

     

    ■CloudStack4.4.0 ※おまけ

    構成:XenServer6.2,FCストレージ

    4.3構築直前時に4.4がリリースされたため、問題がなければ使ってみる事にしました。


    問題多すぎて手に負えませんでした
     
    • ログにUnknown Parameter のWARNINGの大量発生
    • デプロイ時に時々ディスクの作成に失敗する
    • ISOboot時にディスク作成に失敗する
    • 5つ連続でインスタンスの作成時に4つ失敗しErrとなる。その際XenServer上ではサスペンドインスタンスが残されたままとなる。
    • インスタンスを削除するとまれに停止に失敗してしまう。
    • ホスト機をメンテナンスモードにした所、ライブマイグレーションが行われ、正常に稼働していたが、数分後に移行したインスタンスが全台停止した。
    • 停止インスタンスに対して「別のプライマリストレージへのインスタンスの移動」で、iSCSI←→FCへ移すと失敗し、データが消えて起動しなくなる。

     → ホスト−ストレージ間に関する問題の様に見受けられるが、検証が1日未満であったため、直ぐに中止して4.3を使うことにしました。


    最後まで読んでくださった方、恐縮です。
    ありがとうございました。

     

    PR

    calendar

    S M T W T F S
         12
    3456789
    10111213141516
    17181920212223
    24252627282930
    << September 2017 >>

    selected entries

    categories

    archives

    recommend

    links

    profile

    search this site.

    others

    mobile

    qrcode

    powered

    無料ブログ作成サービス JUGEM