涅槃を目指す

ネガティブなことばかり言う人が多い職場は嫌だな

2019/10/29 に サイボウズ東京オフィス で開かれた SRE Lounge #11 に参加しました。

eureka さん、サイボウズさん、Repro さん、各社SREの取り組みの話を伺う事が出来ました。

eurekaのパフォーマンス定点観測会の取り組み紹介2019 @dharada1/@kai_ten_sushi さん

パフォ会っていうのをやっている

APIチームとSREチームのパフォ会

可用性やパフォーマンス向上を目的とした週次MTG

SREとAPIチームでやってる

基本的にDatadogのメトリクスを集めてて、それを見る回

この会で発生するタスクは3つまでという制限

事業から見た優先度が低く、枝葉のタスクに集中しないような仕組み

SLIとSLO

SLIは（総リクエスト-500系エラーリクエスト）/総リクエスト数

SLO：99.5%

エンドポイントごとのレスポンスタイム

nginxのログをBigqueryにいれてLambdaで集計

DBパフォーマンスも見てる

スロークエリ

デッドロック

Toil

Oncall対応とかを棚卸

SREだけのパフォ会

従量課金のコスト監視

バジェット

インフラのメトリクス

断捨離とキャパプラ

パフォーマンスの異常検知

コストパフォーマンスは悪化してないか

アラートの断捨離

なり続けているalertはないか

どのアラートが何回なったか

曜日×時間のヒートマップ

週ごとのアラート件数

パフォ会で得た知見

指標化は大事

SLI

SLIからブレイクダウン可能な形でメトリクスを可視化

何を見るか/意識するか

KPI Treeとかを作ってもいいかも

SLO

合意された目標

目標・会議体を常に澪直していく

課題感は常に変わる

指標化と目標設定、注力する部分の見直しが必要

ツールに集約するのは大事

Datadogは扱いやすい

本質的な仕事に集約

質問

ただの閲覧と決済系では、同じ500エラーでも重みが違う場合があるがその辺の考慮はしているか

課題として認識してる。考慮中

Cybozuにおける大規模インフラ基盤の移行プロジェクトManekiの紹介 Cybozu @_a0i さん

サービス成長に伴って、データ量も大きくなってるので、基盤移行プロジェクト（Neco)が動き出した

k8s、Ceph、Rookが中心

移行プロジェクトがManeki

Necoチームと移行専門のManekiチームがいる

検索基盤の移行

Elasticsearchが1つで、Diskが複数だった構成から、マルチノードのElasticsearchに移行

Elastic Cloud on Kubernetes

indexのサイズ制限をしなかったので1TB級のindexが生まれた

indexをshardに分割しようにも、分けすぎたり大きすぎたりすると遅くな

k8sの課題

yamlの管理

ArgoCDを使ってる、Gitにpushするとデプロイしてくれる

環境ごとにymlを書き換えたい

kustomizeつかう。ベースのYAMLをカスタマイズする

ArgoCDと組み合わせ

監視

PromethuesとGrafana、pagerdutyも使ってる

質問

ログ基盤はどうする予定なのか

Lokiを考えている

安定・安価な ECS auto scaling を目指して Repro @a_bicky さん

ECS使ってautoscalingしたい

ECSの基礎

Task Definitions

1つ以上のコンテナの定義

Tasks

Task Definitionsから生まれたコンテナ群

Task Definitions=クラス、Tasks=インスタンス

Services

Task をdesired countの数だけ起動する

Clusters

taskを動かすためのハコ

ECS Autoscaler

Cloudwatchのalermの状態をもとに、ECSのdesired countを増減する

Spot instanceのinterruption warningをうけとったらdrainingする

Fargateは起動が遅かったり割高なので不採用。バッチでは使ってる

ECS autoscalingの課題

やみくもにdesired countを増やすと起動に時間がかかる時がある

AZの均衡が崩れるとtaskが動いているインスタンスでも落とされる

これからの課題

解像度1分のCloudwatch Metricsだとautoscalingが間に合わないことがある

明らかに異常なリクエストがあっても許容している

Fargateやk8sの検証をやりたい

SREの守備範囲が広がりすぎている

感想

作って終わりではないSaaS型サービスが主流の今、SREのようなRoleはますます重要度を増すと思います。

目的をしっかりと捉えつつ、SLIやSLOといった指標の定義、k8sやprometheus、ECS Autoscalingといった流行りの手段を用いて解決に向かっている姿勢が印象的でした。

当日の様子は togetter にもあるので合わせてご参照ください。

また来年にはSREが主体の大型イベント SRE NEXT が開催されます。

JAWS-UG コンテナ支部 #13 に行ってました。JAWSのイベントは今回が初めてです。

その想い出をWillgate Advent Calendar 2018 の22日目として書きます。

AWS サービスアップデート @toricls

ECSとFargateにタグ付け可能になってコストやリソースの用途把握が簡単になった

ECSでタスクに対してより安全に秘密情報を渡せるように

AWS Cloud Map

すべてのクラウドリソースの動的な地図を作れる

DNSのようにサービスを名前で管理する

属性情報を持てるのでバージョンも表現可能！ 変更後の伝搬は5秒くらい

Cloud MapはAWSサービスだけじゃなくk8sやIstioとも喋れる

App Mesh

App MeshはEnvoyを使ってる。サイドカーコンテナに共通処理をやらせてる

今はプレビュー版。コンソールはなくてCLIとかSDK経由でAPIたたく

Fargate

ログドライバー追加予定（fluentd,syslog）

EKSでは同時に3バーションのKubernetesをサポート

Kubernetes on AWS ベストプラクティス @mumoshu

EKSの特徴

Masterの無停止バージョンアップ

AWSによる自動セキュリティパッチ

VPC、IAM、CloudMapとの統合

kub-aws、kopsのスコープの違い

kops：terraformで様々なホストOSに対応

kube-aws：Cloudformationでクラスタ作成

EKSとは何か

kubernetes control plane のマネージドサービス

今日から始める場合

小さく始める。トライアルならManagedで始める

CloudWatch Logs や CloudWatch Metrics などと組み合わせる

Lambda・EKS・ECSの選択

単発のものならLambda

シンプルにコンテナ使いたいならECSやFargate

k8sの高い拡張性やPaaS基盤的なものが欲しいならEKSやk8s

初心者はkubectl,ubedns,eksctl あたりから始めるとよさそう

運用のコツ

EC2メタデータサービスは無効にしないとセキュリティホールに

PersistentVolumeは使わず、RDSやS3のようなもマネージドなものを検討する

Ingress と ELBみたいな機能重複が多いのでよく考える。AWSにロックインされた方がいいのでは

クラスタを分けて全部落ちるのを防ぐ（AZ単位とか）。爆発半径を小さく

Firecracker とは何か - AWS はなぜ軽量 VM を作り私たちはそこから何を享受できるのか @pottava

AWSはなぜ作ったのか

Lambdaは現在EC2ベース

次世代のサーバーレス基盤が欲しい

もっと高速で軽量なhyper-visorが欲しい

Firecracker とは何か

コンテナのためのQEMU代替

VM内でinitプロセスが走るまで125ms以内

firecracker-containerd というランタイムも開発中

以下はLTです

envoyをわかりやすく伝える @_mpon

雰囲気でEnvoyを理解していた僕には非常にありがたいお話でした。 Nginxと比較して語ってくれたのでとても分かりやすかったです。

詳細な解説はre:Invent 2018 で発表されたAWS App Meshの仕組みを解説しますを見てください。

EKSとExternalDNSとACMを利用して、いい感じにHTTPSでサービス公開をしてみた @sugimount

EKSとExternalDNSとACMを使ってHTTPSサービスを公開するまでのチュートリアルを紹介してくれました。ハマりどころがいくつかあったそうですが、これを見ればスムーズに作れそうだと感じました。

GameDay @ re:Invent のこと

英語があまりしゃべれないけど AWS re:Invent でGameDay で外国人と協力して頑張ったお話。 つたない英語でも役に立つアピールで頑張って優勝したそうです！なんというメンタル…

Virtual Kubelet + Fargate + EKSでノードレスKubernetesを夢見た話 @bbrfkr

kubernetes外のAPIにPOD作成を依頼できる Virtual Kubelet を使ってノードレス Kubernetes を作成するデモを見せてくれました。

感想

初めてのJAWSだったのですが、量、質ともの凄くレベルが高くて勉強になりました。 僕は普段 Rancher JPの運営をやってるのですが、負けないように頑張ろうと思いました。

個人的には @mumoshu さん の発表が衝撃で、内容の濃さもさることなんですが、特にAWSとk8sで競合する機能があればAWSを選ぶという考えはとても新鮮でした。

僕自身、CloudStackやRancherといった特定のクラウドやベンダーに依存しないOSSからこの世界に傾倒していった人間なせいか、そういった観点は全くなく、クラウドネイティブに縛られずに、それぞれのクラウドの特性を活かして自分らの欲しいものを作り上げていくという考えは非常に新鮮ででした。僕自身が「クラウドネイティブ」というものにロックインされていたのかもしれませんね。

ただ、そうなってくるとインフラエンジニアと呼ばれる人たちは、非常にたくさんの選択肢の中から自分らの欲しいもの、時には顧客が望むものを作ることになって、これはなかなかシンドイ話ではないのか。とも思いました。

ssmjp 2018/10 Ansibleを語る回@dmm.com に参加してきました。

今回はAnsibleのお話です。

Ansible ではじめるサーバー・ネットワークの自動化 (Ansible2.7情報つき)@akira6592さん

Ansibleではじめるサーバー・ネットワークの自動化（2018/10/12） from akira6592

Ansibleの概要としては

シンプル（Playbook）

パワフル（多数のモジュールがあってサーバ、クラウド、NW機器向

エージェントレス

というのがあり、シェルと比較すると

モジュールを利用することでコマンドを直接書かなくてよい

エラーの扱いが楽

冪等性がある

ほかのAnsibleと連携できる

などの特徴がある。動作環境はPython環境があればよい。

Ansibleの構成要素としては

インベントリ：対象のホスト情報（IPアドレス、ホスト名。グループ化も可能）

モジュール：機能単位。利用するモジュールとオプションを利用。yumモジュールやios_configモジュールなど、現在は1900以上ある。（モジュール一覧はコチラ）

Playbook：構成定義。YAMLフォーマット。スペースの数で構造定義をしてる

ansible.cfg：環境設定。Ansibleの動作を決める

2.7アップデート情報は

230以上のモジュール追加(GCP絡みが増えた）

コントロールノードでPython2.6非サポート

pipモジュールで、nameのリスト指定とバージョンが併用可能になった

無効なタスク属性がデフォルトでエラーに（2.6まではWARNING)

CHANGELOGはコチラ

やはり公式文書を参考にして色々なモジュールを探したりしながらやっていくのが基本みたいです。

定期的にもくもく会を開催していたり、Slackもあるので気楽に参加して下さいとのことです。

Ansibleで始めるNW設定の自動化について 〜Cisco(VIRL)編〜 (仮)@すがいさん

AnsibleではじめるNW設定の自動化について - Cisco(VIRL)編 - from Yasuyuki Sugai

モジュールを使って色々なNW機器に設定できるんだけど、イマイチ情報が少ないので実演してみるというお話。

まずVIRLの紹介

CiscoのNWシミュレータ。有償だけど便利

環境をVMイメージで配布

スペックは結構求められる

NW構成の作成も自由に簡単にできる

VIRL外のNWにも接続可能

他ベンダーのOS（BigIPとかFortigate）も搭載可能

VIRLはOpenstack構成

最大5ノードでクラスタを組める

次はngrokの紹介

ローカルのPORTをSSHトンネルで公開できるngrok（https://ngrok.com/）が便利

実際にやってみる

モジュールがたくさんあるので公式から探す

モジュールだけではできないことがまだあるので、 割り切りが大事 

ios_configモジュールというコマンドを直接送り込むこともできる。show run との差分を見てから実行する

playbookを固定化し、動的なものは変数化したい

NW自動化に向けた課題

複雑になり定型化できない

管理するパラメータが多い

問題があった時の切り戻し

質疑応答

Q.初期はipアドレスすらない状態だが、そういったところの自動化はどうするのか。

A.初期設定はどうしても手作業になっちゃうけど、変更の多いNW機器だとメリットがあるのでは。

@akira6592さんからの回答

IP到達性のないネットワーク機器をコンソールサーバー経由Ansibleで操作するというのを、Interopでセイコーソリューションズさんが参考出展されていました。 #ssmjp https://t.co/WijJPg0J6B

— よこち(yokochi) (@akira6592)

2018年10月12日

Q.モジュールの粒度が細かいので、まとまった便利なモジュールないのか。探すのが面倒

A.ないので、機器に対応したものを選ばないとだめ。モジュールはベンダー機器に合わせたものをキャッチアップしていくほうが確実

残念な現場にAnsibleを適応してみた過去と現在と未来@togakushiさん

割と非公開ネタ114ページ

残念な情報は非公開。面倒かつ非効率なことが多く大変なところにAnsible導入

踏み台が複数あるような複雑な環境も工夫してAnsibleで乗り切れた

本日から株式会社ウィルゲートにて働きます！ よろしくお願いしまっす！

SIerからWeb系への転身です。

あとはおっさんの転職ポエムが続くので、気になる人だけ見てください。

この道を行けばどうなるものか　危ぶむなかれ　危ぶめば道はなし　 踏み出せばその一足が道となり　その一足が道となる　 迷わず行けよ　行けばわかるさ - アントニオ猪木 -

転職の動機

僕は40くらいのオッサンで、30まではフラフラと飲食店で働いたりしてました。

30で前職である中小SIerに何とか滑り込んで、そこで最初の2年はCOBOLerで銀行とか信販とかでExcelにお絵かきをしていたのですが、コンピュータサイエンスからかけ離れたこの現状があまりにもおかしいと思ったので、 インフラエンジニアに志願して Oracle の資格を取得し、 OracleDatabase の設計構築を2年ほど行いました。

そうこうしてるうちに自社が サーバ室をちゃんと構えられる自社ビルを建て、そこにプライベートクラウドを構築し、自社サービスを展開する事になりました。

「お前ひとりでなんかそういう基盤を作れ」という雑な指示のもと一人で自社サービスの基盤としてのプライベートクラウドを構築し、そのまま自社サービスのインフラ担当兼、開発環境や勤怠管理といった自社システムの管理。いわゆる一人情シス状態を5年くらいやりました。

しかし、このまま下請けSI会社でやって行く不安と、会社として自社サービスに対する投資をちょっと控える動きがあり、自分の手でサービスを作ってお客様に使って頂いたのが凄く嬉しかった僕は転職を考えるようになりました。

やった事

まずエージェントに相談しました。このツイートは去年の12月ですね。

そこで「まぁ確かにオッサンだけど、そんなに糞スキルでもないから何とかなるんじゃない？」とか言われて安心しました。

でも12月からずーっと転職活動してたわけではなく、転職サイトをチラチラ見るくらいの転職活動とは言えないくらいの状態が続き、そして夏に一大決心をして本格的に活動を始めました。

条件としてはこんな感じです。我ながらフワッとしてます。

年収が下がらない

下請けのSIとかじゃなく、自社でビジネスをちゃんと回せてる

インフラエンジニアとして働ける

チャレンジできる土壌がある

ビズリーチに登録しつつ、2社のエージェントに紹介してもらう形を取りました。

エージェントに「自社サービスをやってる会社のインフラ or 社内SE」という条件で探してもらったら90社くらい紹介されて辟易としました。「こういうことをやりたい」とか「この会社に入りたい」みたいなのがハッキリとしない状態で辞めること自体を目的とすると結構悩みそうですね。

それ以外にも「YOU！ウチくる？」みたいな感じで声をかけてもらい、いわゆるリファラル採用での選考もして頂きました。2社とも立派な企業だったので声をかけてもらうだけでも嬉しかったです。

職務経歴書を真面目に書いたのが良かったのか、ビズリーチ経由で企業から直接のスカウトも何社か頂きました。

また、 転職日記 -三日目-  にも書きましたが、OSSコミュニティ経由で知り合った渋谷の社長に相談に乗って頂いたのも有難かったです。

結果

22社受けて結果としては

書類選考でお祈り：13社

面接でお祈り：5社

面接で辞退：2社

内定：2社

となりました。

実際の転職活動期間は1.5か月くらいです。複数社を受けていたので面接のスケジュール調整をしてくれたエージェントには助けられました。

お祈りの理由で多かったのは「オッサンの癖にこれといった強みがない」でした。一人情シスは守備範囲の広さを要求される場面が多く、その状況に甘え、強みを作ろうとしなかった自分の責任であります。アピールも上手くなかったかなぁ…自己アピールの素振りもっとやっておけばよかったな…

こっちの職務経歴書を半笑いで見たり、自己紹介中に吹き出されたりという屈辱も味わいました。終わったことだからもういいけど、どうか地獄の業火に焼かれるか、親知らずが無限に生え続ける呪いにかかって下さい。

内定貰った時はホントに嬉しくてスタバで変な声出そうでした。

内定のポイントとしては、オンプレからクラウドまでの両環境において非機能要件定義から運用までの経験があるっていうのが良かったみたいです。幅の広さが評価されました。

幸運にも2社から内定頂いて結構悩んだんですけどウィルゲートに決めました。

決め手は以下4点

社長や経営層の描くビジョンが社員まで浸透してる

色々とチャレンジしててなんか面白そう

面接して頂いた方々の感じが良かった

直近3年の決算公告見る限り堅調

ウィルゲートはエージェント経由ではなく、ビズリーチ経由で直接スカウトを頂いた会社でした。

ありがとう！ビズリーチ！ごめんねエージェント

今後

Rancherと私 にも書きましたが、 CloudStackユーザ会、Rancher JP、OSPNといったOSSコミュニティの方々と関わるようになってから人生が変わったと思ってます。SIで現場に出てるときより遥かに世界が広がりました。

OUTPUTしろ！とか起業しろ！とまでは言いませんが自分以外の世界を知るのはいい機会だと思うので、なんか煮詰まってる方は、何らかの勉強会とかコミュニティに接してみることをお勧めします。

XenServer の inode が枯渇したというお話。 とっくに解決した問題なんですが、備忘のためにメモします。

調子の悪くなった XenServer を発見。ssh はいいんだけど、API を使った連携もできず、XAPI(管理ツール)の再起動もできない。バージョンは6.2と古くてサポート切れ。

なんだよもーって感じで調べるも、なんでかわからん。本番稼働中なので再起動も許されない。冗長化してるんだけど、VM移動の瞬間停止すら駄目って鬼畜かよ。

なんか変だなー怖いなーって稲川淳二っぽく色々調べてたらこれですよ

# df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 524288 524288 0 100% / none 94257 8 94249 1% /dev/shm /opt/xensource/packages/iso/XenCenter.iso 0 0 0 - /var/xen/xc-install

inodeが枯渇！なんで？

どこのどいつだって調べていったらこいつですわ

# find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n -r |more 480750 /var/lock/sm/lvm-e2e73bc8-7db3-f061-22e9-0345bacb5229 1056 /var/xapi/blobs/messages/uuids 1056 /var/xapi/blobs/messages/refs 1056 /var/xapi/blobs/messages/gen 777 /usr/share/man/man1 666 /usr/bin 586 /usr/share/man/man3 585 /usr/lib/python2.4 560 /usr/share/locale

/var/lock/sm/lvm-e2e73bc8-7db3-f061-22e9-0345bacb5229 ていうディレクトリに48万個のファイル？

どうも lock ファイルみたいなのがいっぱい入ってる。うかつに消せないしどうしよう。

XenServer 使ってる人あんま居ないし…

なので海外のフォーラム 「Citrix Forums - Discussions」 で聞いてみました。なんか本家っぽいし強そうだ。

高校の時に取った英検2級を武器にスレ立てました。緊張したなー。

作ったのがこのスレ inode is Almost empty - Command-Line Interface - Discussions

立てて数時間後にはレスが来て嬉しかった。やっぱ本場は違うね。

立てた後に、なんで A だけ大文字なんだとか思ったけど、誰もそんな野暮な突込みはせずに優しく教えてくれた。

2人に回答してもらいました。一人はアーカンソー州ロジャース市の職員？ もう一人はCitrix Technology Professional かつ NVIDIA GPU Community Advocacy。NVIDIAのGPUコミュニティの提唱者？エバンジェリスト的な人なのかな？。

2人のアドバイスを要約すると

こんなの始めてみたw

起動後のは触れないけど、古いロックファイルは消えるはずだけどなあ

/var/log の中消すか、他のストレージにvm移せば綺麗になるかもなあ

SR（ストレージリポジトリ）のロックファイルっぽいけど、そんなにinode消費してる理由は知らんわ

てかその XenServer 古くね？セキュリティ的な問題もあるから更新しろよw

ですよねー。更新しろって話ですよね。

このあとおとなしく最新化しました。「df -i」に気づくのに二日かかりました。

2台構成のpoolのmasterと通信できなくなった… XenServerのバージョンは7.1

xencenterはこんなエラー

サーバのコンソールはこんな感じで操作不能

sshで接続してみよう

# ssh root@ipアドレス ssh_exchange_identification: Connection closed by remote host

え？なんで？

# ssh -v root@ipアドレス OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 56: Applying options for * debug1: Connecting to ipアドレス [ipアドレス] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 ssh_exchange_identification: Connection closed by remote host

なんやのー

~/.ssh/known_hosts 消してもダメ

XenServerは多くの通信で tcp/443 を使う。XenCenterとの通信もだ。curlしてみよう。

マトモなXenServerにつなぐとこうなる

# curl --insecure -D - -o /dev/null https://ipアドレス:443 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0HTTP/1.1 200 OK content-length: 4426 connection:keep-alive content-type:text/html 100 4426 100 4426 0 0 33036 0 --:--:-- --:--:-- --:--:-- 33278

んで、繋がらない方にcurlしてみると

# curl --insecure -D - -o /dev/null https://ipアドレス:443 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (35) Encountered end of file

EOFて何でやねん。

slaveにログインしてxeコマンド

# xe pool-list The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. # xe host-list The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: INTERNAL_ERROR: [ Cli_protocol.Unmarshal_failure(_, "") ] # xe vm-list The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: Xmlrpc_client.Stunnel_connection_fail

まとめると

コンソール：操作不能

ssh：×

tcp/4443：×

xeコマンド：×

なんすかこれ

なんなんすかこれ

どうせっちゅうのよ。。。。マスタ上のvmは稼働してるので、下手に手が出せん。

せめてマスタ上のvmを正常稼働してるslaveにマイグレーションしたい

# xe vm-migrate host=ccndmg01 The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: Xmlrpc_client.Stunnel_connection_failed

やっぱ通信できないから無理だよねそりゃ

vmには通信できるから、Dom0に通信できなくなってるんだよな。はぁ

IMMで見てもサーバに異常は起きていない。どー見ても異常なんですけど

Dom0がハングしてるんだろうな。強制再起動しかないか…

24時間たっても状況変わらずなので強制再起動した。なーむー

無事再起動できた！vmも大丈夫！やれやれだぜ

しかしなんでハングしたんだろ？

ログ見てみるか

何も出てねえ…

てか、sarのログなんかは普通に出てるんだよな…NICだけハング？

XenServer界を震撼させた前回の投稿ですが、前回の結びで

XenCenterをダウングレード

心臓に優しいアイコンに仕様変更するのを待つ

という提起をしていました。

ところが、XenCenterとXenServerは互換性の問題があって、

XenCenterのバージョンがXenServerより古いと接続できないという仕様があってですね、こんなエラーが出ます。

さー困った。最新のXenServerを使うには最新のXenCenterが必要だけど、Unlicensedって出ちゃう。

そこで登場したのが Xen Orchestra です。

Xen Orchestra とは

Vatesという会社が作っている、XenServerをWebGUIで管理できるツールです。公式Doc

Free版と有償版があって、Free版は、OVA/XVAのexport/importが出来なかったりします。（Xen Orchestra Pricing）

アーキテクチャとしては、クライアントにインストールするXenCenterとは違い、XOA（Xen Orchestra Applianceかな？）というVMをXenServerにimportし、XOAのWebインターフェースに接続して使います。詳しくはこっち見てください。

XOAのインストール

すっごい簡単でコマンド1発で入ります。XenServerのDom0にログインして以下のコマンドを打つだけです。

bash -c "$(curl -s http://xoa.io/deploy)"

そうすると、VMのimportとセットアップが始まります。

Welcome to the XOA auto-deploy script!

Network settings: IP address? [dhcp] xxx.xxx.xxx.xxx Netmask? [255.255.255.0] 255.255.255.0 Gateway? xxx.xxx.xxx.xxx dns? [8.8.8.8] xxx.xxx.xxx.xxx Importing XOA VM… Booting XOA VM… Waiting for your XOA to be ready…

Your XOA is ready on https://IP or Hostname/

Default UI credentials: [email protected]/admin Default console credentials: xoa/xoa

VM UUID: 1fe0788b-cc63-1efa-359f-705c950d0034

しばらく待ってhttps://IP or Hostname/にアクセスすると Xen OrchestraのUIに接続できます。XOA自体は

2 vCPUs

2GB of RAM

15GB of disk (10GB for / and 5GB for /var)

が必要なリソースです。

無事VMが出来ると以下の様なログイン画面が出るので

あとは、Hostを追加していって下さい。

そうすると、VM一覧やらHost一覧を見ることができるようなります。

画面はVM一覧です。

各バージョンのXenServerを見ても"Unlisenced"なんか出ません。

7.4がFree！

6.2もFree！

弊社、5年くらい前からXenServerを愛用しております。バージョンは5.xあたりからかな？

新しく環境を作ろうとして最新のXenServer7.4のisoを落として、ついでにクライアントツールのXenCenter（vCenter的なものです）も最新のを落として起動し、ホスト一覧見たらこの有様ですよ。

今まで無かったのに、急にビックリマークが勢ぞろい！

本番機もあるので情シスとしては「ハイ死んだ！」と思うわけですよ。

でも、「クライアントツールのバージョン上げただけで死ぬわけないじゃないか」と冷静になってよく見ると、Statusが「Unlicensed」になってる。画面に出ているXenServerのバージョンは全て6.5です。

たしかに結構前のバージョン（6.2より前だったかな？）だと、Free版であってもライセンスキーを入れる作業が必要で、1年の有効期限が切れるとVMの操作ができなくなるとかだったんですが、6.２以降（だったかな？）をFreeで使うときはライセンス関連の操作が全て不要になって、便利になったと感心しました。

でも最新のXenCenterが「ライセンスがねーよ！」と怒ってるわけですよ。

うーん、困ったなー。なんで前のような挙動に戻すのよー。ググっても90日間の試用ライセンスしかないし、画面的に気持ち悪いので色々調べてみるとcitrixのforumで以下のようなやり取りがありました。7.3でも同様みたいですね。

俺は今7.3をテストしてるんだけど、"Unlicensed"がホスト名の近くに出てるんだ。Free版で行きたいんだけど、この表示消す方法ある？

するとこんな回答。

もうライセンス済みじゃない？"Unlicensed"てのはFreeの意味なんだ。これ以上インストールするフリーラインセンスっていうのは俺の知ってる限りは無いね、とにかくfreeとUnlicensedていうのは同じ意味なんだよ。

え？ビックリマーク消せないの？

この後は

このアイコンは気にくわない

改悪だ

そんなにライセンス買わせたいのか

せめて"Free"て書いてある緑のアイコンにしてよ

もうやってられるか！俺はproxmoxに移行したぞ！アバヨ！

みたいなやり取りが続いてます。

確かに嫌ですねコレ。

XenCenterをダウングレード

心臓に優しいアイコンに仕様変更するのを待つ

どっちかかな？

XenServer7.4を古いバージョンのXenCenterで見た時の挙動は今度確認します。

NW構成図と一人情シス

一人情シスには「NW構成図の更新」という神事があります。

これはただのNW構成図の更新作業などではなく、この図を片手に後輩や新人にNW構成を説明する自分を想像しながら 「こうした方が分かりやすいかな？」「これじゃ独りよがりかなウフフ」などと考えながら作成するものの、結局誰にも引き継がれる事なく自分でメンテナンスし続けるという、セルフ賽の河原のようなものです。

今回は物理構成図の話をします。論理構成図でも同じ悲しみを味わうのですが、それはまた別の機会に。

今まで

今まではvisioで作成してて、以下の点に気を付けていました。

分かりにくくなるため、なるべく線を交差させない

接続状況が分かりにくくなるため写真やベンダー提供のアイコンを使わず、ハコで書く。

各機器がどのPortで接続しているか把握できるように書く。

で、出来たのが以下の図です。

課題

頑張って書いたけど、以下のような課題がありました。

真ん中の48PortのL2のように、Port数が多い機器のハコがどうしても大きくなり、実際のラック格納状態と乖離してくる。

線が多くて追いかけづらい

結局交差しちゃう

あんまり綺麗じゃない

やってみた

今回は以下の点に気を付けました。visioを止めてdraw.ioでやってみました。

ハコではなく汎用イメージを使い、大きさを揃える

機器同士の接続が複数Portの場合は、線をまとめて1本で表現する

接続Portは線の上に、機器に近づけて記載する

実際のRack格納状態と乖離しないようにする

なるべく線が交差しないようにする。でも多少はしょうがないよ。人間だもの

今回はこんな感じになりました。

箱の大きさがそろったので、Rackの格納状態とも乖離しなくなりました。

レイヤを重ねるとこんな感じです。「Blade System」て書いてますけど、HPEさんの製品とは無関係です。

感想

（これはRancher Glossary: 1.6 to 2.0 Terms and Conceptsの翻訳記事です。）

Rancher 2.0 の開発プロセスが終わりに近づいてきたので、私たちは Rancher ユーザが Kubernetes や Rancher の基本的な概念を理解するのに役立つ用語集を提供するのが良いでは、と考えるようになりました。

Rancher 1.6 から 2.0 への移行に伴い、 Kubernetes の命名標準に沿ったものに調整しました。この変更は Rancher 1.6 において Cattle のみを使ってきた人たちに混乱を招く可能性があります。

この記事は Rancher 2.0 の新しい概念の理解を手助けする事を目的としていますが、 Cattle と Kubernetes という2つのコンテナオーケストレータの用語や概念の簡単なリファレンスとしても使えます。

Rancher 2.0 Kubernetes と比較した Rancher 1.6 Cattle

Rancher 1.6 は Cattle をコンテナオーケストレータとして提供し、多くのユーザがこれを選択しています。 Cattle においては、管理と計算資源の境界、つまり権限を割り当てることのできる最小レベルの単位として 環境（ Environment ） があります。重要なことに、その環境内のホストはその環境専用のものであり、その環境でしか使用できませんでした。そして、コンテナを整理するためにサービスを論理的にまとめたスタック （ Stack ） というものがありました。サービスは特定の実行イメージです。

では、この構造は 2.0 ではどのように見えるのでしょうか。

もしあなたがコンテナ界隈で働いているならば、Pod、namespace、node といった Kubernetes 周りのバズワードを聞いたことがないという事はないでしょう。この記事の目的は Cattle , Kubernetes 両方の用語を整理することで Cattle から Kubernetes への移行を簡単にすることです。いくつかの名前が変更されると共に、いくつかの機能が変更されています。

以下の表は Kubernetes のコアとなる概念を記載してます。

概念 定義 Cluster Kubernetesで管理されている、コンテナ化されたアプリケーションを実行するマシンの集合。 Namespace 1つの物理クラスタで複数の仮想クラスタをサポートできる仮想クラスタ。 Node クラスタを構成する物理（仮想）マシンの一つ Pod 最も小さくてシンプルな Kubernetes オブジェクト。Pod はクラスタで実行されるコンテナのセットのこと。 Deployment 複製されたアプリケーションを管理する API オブジェクト Workload クラスタで実行される単位。 pod や deployment にもこれに当てはまります

より詳細な Kubernetes の概念は以下の以下の記事を参考にしてください。https://kubernetes.io/docs/concepts/

環境 （ ENVIRONMENT ）

Rancher 1.6 において環境は2つの事を表現していました。

計算資源の境界

管理領域の境界

2.0 では環境という概念はありません、代わりに以下のものに置き換えられます。

Cluster - 計算資源の境界

Project - 管理領域の境界

Project は Kubernetes の管理負担を軽減するために Rancher が導入した管理レイヤです。

ホスト（ HOST ）

Cattle では、ホストは１つの環境にしか所属してないことがありました。それと類似して nodes （ホストの新しい名前！）は1つのクラスタにしか所属していません。以前はホストと環境でしたが、今は nodes と cluster です。

スタック （ STACK ）

Rancher 1.6 のスタックはいくつかのサービスをグループ化する方法です。Rancher 2.0 では、これは namespace によって行われます。

サービス （ SERVICE ）

Rancher 1.6 では、同じコンテナを実行している1つ以上のインスタンスをサービスと定義していました。Rancher 2.0 では同じコンテナを実行している1つ以上のインスタンスを workload と定義しています。workload はコントローラーと実行される Pod(s) で構成されます。

コンテナ （CONTAINER）

コンテナイメージは軽量でスタンドアロンで実行可能なソフトウェアのパッケージです。中にはソフトウェアの実行に必要なコード、ランタイム、システムツール、ライブラリ、設定などが含まれています。Rancher 1.6 では、コンテナはアプリケーションを実行するのに必要な最小の定義でした。Kubernetes においては、Pod が最小の定義です。Pod はシングルイメージでも、複数のイメージにすることもできます。複数の場合は同じストレージ/ネットワーク、そしてそれらがお互いにどのように動くかという定義を共有します。Pod は常に同じように配置、スケジューリングされ、共有されたコンテキストで実行されます 。

ロードバランサ（ LOAD BALANCER）

Rancher 1.6 では、ロードバランサは Rancher の環境にあるアプリケーションを外部からアクセス可能にするために使われていました。Rancher 2.0 でもその概念は同じです。サービスを公開するロードバランサーオプションがあります。Kubernetes の用語では、この機能は Ingress を指すことが多いです。要するに、ロードバランサと Ingress は同じ役割を果たします。

まとめ

概念という点においては、Cattle はオーケストレータの中で最も Kubernetes に近いオーケストレータでした。うまくいけば、この記事は Rancher 1.6 から 2.0 に移行する人たちへの簡易リファレンスとなる事でしょう。この2つのオーケストレータの類似性は、より簡単な移行を可能にするはずです。

以下の表は新旧の用語のクイックリファレンスです

Rancher 1.6 Rancher 2.0 Container Pod Services Workload Load Balancer Ingress Stack Namespace Environment Project (Administration)/Cluster (Compute) Host Node Catalog Helm

LForMて何？

株式会社エーピーコミュニケーションズさんが公開している、ネットワーク機器のリアルタイムログ解析ツールです。公式サイト

OSSで公開されていてFortiGateに対応しているとのことなので、社内のFortiGateで試してみました。

インストール

LForMダウンロードに必要事項を記入するとマニュアルURLがメールされてくるので、その通りにやってください。簡単でしたよ。

公式にも説明がありますが、fluentdでSNMPやSyslogデータを受け取りelasticsearchに保存し、kibanaで見る仕組みのようです。nginxはbasic認証のために置いたのかな？弊社でも同じような構成でログの監視をしています。

今回の環境

今回は以下の環境で試しました。動作確認済みのファーム（FortiOS）は5.2.3とのことですが、最新の5.6.3でやってみました。

兄さん！最新でも大丈夫だったよ！

サーバ：CentOS 7.2（CPU ２コア、MEM 4G）

FortiGate:FortiGate 60E

ファーム：v5.6.3 build1547 (GA)

設定

複雑な設定はありません。ForiGate側でSNMPとsyslogの設定と、サーバ側でSNMPのポーリング設定くらいで動きだします。

実際の画面

あとはhttp://LForMのIPアドレスでOKです。

デフォルトのダッシュボードがイイ感じなので特に何もしなくてもいいくらいでした。

例えばトラフィックを見ると、突然７M程度の何かを受信したことがすぐわかるんですよ。

あとは時間で選択して深堀りしてSource IPを見ると192.168.80.110が何かしてるのが分かる訳ですよ！まあ俺なんですけどねコレ。

使ってみて便利だなと思ったところ

ぶっちゃけ使う前は「FortiGateのダッシュボードでも近いことできるしなあ…」みたいな感じだったんですが、FortiGateのダッシュボードに比べるとかなり使いやすいです。インタラクティブ性が高いのは気持ちいいです。

デフォルトでも十分なんですが、自分好みのVisualizeやdashboardを簡単に作れるのもいいですね。FortiGateはダッシュボードのカスタマイズはできるんですが、ウィジェット（Visualize的なもの）の作成はできないんですよ。

あとFortiGateはログ保存にFortiCloudっていうクラウドサービスを使えるんですが、保存期間は1年です。LForMはそういう制限がないのもいいですね。

期待するところ

ログの保存期間

デフォで放置するとサーバが死ぬまで保存し続けるので、ログの保存期間の設定ができるといいですね。まあelasticsearchだし、自分でcurator入れればいいんですけどね。

レポート機能

月次や週次でレポート送ってくれると運用にも優しくなりそう。kibanaのx-pack（有償）だとレポート機能あるんですけどやっぱねえ、お高いじゃないですか。

Edgeで見れない問題

FirefoxとChromeはOKですが、Edgeだと表示されませんでした。以下の2画面を無限に繰り返します。（Microsoft Edge 41.16299.248.0）

まとめ

ありそうでなかった感じで好きです。いろんな機器にも対応していく感じっぽいので横断的に見れるようなると面白いかも知れませんね。