sidetech

インフラエンジニアの寄り道メモ。

WindowsでPrometheus&Grafanaのまとめ。

出だしは、Azure Insightだったのに終わりはPrometheus?

いあ・・・結局の主役はGrafanaかな?

f:id:hunter1014:20190925164553p:plain

 

そんなこんなで手抜きな記事を連投したので、まとまりも何にもない状況なのですが、タイトルの通り、少しまとめます。

f:id:hunter1014:20190924235441p:plain

画像はAzure Insightからです。図を描かなくて助かる(笑)

ちょっとGrafanaにツッコミですが、「stats.grafana.org」にアクセスしに行っちゃっているのは何なんすかね。何見られているんでしょう?

 

図式でもわかる通り、クライアントはGrafanaを見て、GrafanaはPrometheusとAzure Monitorを見に行く構成を今回は構築しました。

で、Prometheusでは、以下のExporterを使いました。

blackbox_exporter(https://github.com/prometheus/blackbox_exporter)

snmp_exporter(https://github.com/prometheus/snmp_exporter)

・wmi_exporter(https://github.com/martinlindhe/wmi_exporter)

どれもWindows Server 2019 datacenterにぶっこみました。

・Prometheus(https://prometheus.io/download/)

インストールはwmi_exporterだけmsi形式のインストールを使いました。

WIndowsamd64形式を選んでインストールしています。

インストールというか、自由に配置して、exeを起動しているだけですね…。

おそらく、一番難しくないPrometheus&Grafanaでしょう・・・ね。ノーマルなら。

 

 PrometheusのymlなConfigは以下のようにしました。

f:id:hunter1014:20190925000645p:plain

すべて「file_sd_configs」でノードの追加対応をしています。file_sd_configにしておくと、その先のファイルを修正するだけで、どんどん反映されていくのは知っていましたが、Windowsでも同様に機能しました。

 

f:id:hunter1014:20190925154752p:plain

ファイルの中はこんな感じです。ラベルを関係した変数として持っていけるので、こんな感じで仕上げてみました。

 

blackbox_exporterでのICMPチェックの機能は私にとってちょっとどうやって信用していいのかわからない値が返ってくるので、他人様が作っているping_exporterを使ってみたいと思っている所。

(追記)なんと正しい記述方法を見つけて試してみたらいい感じになった(^^;

blog.sidetech.jp

 

snmp_exporterはWindowsでも動きました・・・が、snmp generatorのwindows版がないので、どこかLinux系でMIB食わせて生成させる必要ありです。

どちらにせよ、snmpsnmpが得意な監視ソフトに任せたほうが良いような。

 

wmi_exporterもなんのひねりもなくやってますが、wmiを活用するにはWindows側で頑張る必要があるので、そこはちゃんとみておかないとかな。

 

Grafanaは、結局の所、式を書く方法が何が正解なのか結構色々調べてやらないといけなかったり、他人様のダッシュボードを見ながら研究したりしないといけないので、思い通りに動かすのはちょっと大変ですね。

それとアラートの機能で、テンプレート変数が活用できないオチがありまして。。。

これは、Prometheus Alertを引っ張るプラグインが良さそうな気がしますが、まだ試していません。

 

PrometheusのConfigのとおり、結構なscrapeタイミングで取得を繰り返すとどうなるか。

14~18ノード程度ではありますが、dataフォルダをみたら2.92GBでした。

9/18から動かしているから・・・今日が25日。1週間で3GBってぐらいですかね。

後々、この対処も考えないといけないです。

PrometheusのRemote Stotageというファンクションを使うことになるはずなんですが…さてAzure Storageにどうやって持っていくかな。そもそもAzureストレージをマウントしちゃえばいいかな?

データの太り方がまあ予測しきれていないので、もうちょっと時間が必要ですね。

それと、1回だけグラフ表示が1~2分程度出来ないタイミングがありました。これが先人の方々がいう突然の処理影響ですかね・・・。

 

あと、課題としてはwmiで引っ張った値とAzure Monitorで引っ張った同系の値の乖離をどうするかなとか。単位は同じなのになぁ。何か計算式が足りないんだろうな。活きたデータにするのがとにかく大変ですね。

 

Grafanaを使っていて思うのは、Summaryとなるレポート用画面と、Currentの監視用画面と、Statisticsとなる解析用画面は分けたほうがいいな・・・と感じるところです。いっぺんに・・・は画面が足りません。テンプレート変数の考え方は面白いけど、それによってどうやって画面配置と上記3つの課題を克服するか・・・これが悩みになりますね。

構築後や改変後の動きにはAzure Insightが使えます。プロセス毎に動きが見えて良きかなです。プロセス毎のトラフィックを拾えていたので、アプリケーション毎のトラフィックを見ることが出来ますね。総ネットワーク帯域中、どのアプリケーションがどのくらいの帯域を使っているのか、Grafanaで表現できたら面白そうだなぁ。

 

てことで、Azure InsightとPrometheusアラートの勉強に戻ります。

wmi_exporterを使ってGrafanaで管理してみる

ついに・・・詰んだようです。(-_-;)

どっちにしてもナンセンスな取り組みなんですが、Azure Insightのデータを活用できないか調査もしていないんですが、prometheusのwmi_exporterでWMIの値をゲットしちゃえってことで、とにかく手っ取り早いだろと思ったんで、はじめてみました。

Azure Monitorではメモリとかディスク使用量はわからんっす。
なので、wmi_exporterエージェントをWindows Serverに仕込んでもう、WMIに直に教えてもらう。そーいう話です。

f:id:hunter1014:20190924032946p:plain

そして~他人様が作ったダッシュボードを利用して変数を変更しただけで、WMIの値はゲットっす。しかし、見てもヨクワカラン値のグラフが多いですな。。。

まぁ、とりあえずメモリ使用率とディスク使用率が欲しいためだけにwmi_exporterに手軽く手を出しただけですので、まぁ細かいことは置いときましょう。

取り合えず、人様のダッシュボードを使っただけなので、他にもまだ取得できると思います。

 

で、メモリとディスクの使用率が気になるということは・・・しきい値アラートの設定ですよね(勝手な流れ的ですが)。

そして、アラート設定を仕掛けてみた所・・・

f:id:hunter1014:20190924033442p:plain

(;゚Д゚)えっ?!?!?!

Grafanaさん!、テンプレート変数はサポートしていない・・・?っておっしゃっています?!

 

えーと・・・せっかく・・・テンプレート変数面白いなぁ~って思ってきたところで叩き落とす?!?!(;´∀`)

 

とりあえず、テストでアラート飛ばしてみたけど・・・確かメトリック名もバリューもNullっぽい。まぁどのインスタンスからエラーなのか判らなくてもいいならアラートは飛ばせる・・・(汗)

 

一応、テンプレート変数を使わない方法で、アラート飛ばしてみたら、問題はなかった・・・。

f:id:hunter1014:20190924034234p:plain

いあ、こんなグラフ付けられたアラート見てもねぇ・・・。(;^_^A

 

このせいで、先人の開拓者はPrometheusでアラート管理やってるん?!

てっきりGrafanaのAlert対応が最近なせいかと思ってた・・・orz

 

グラフ表示とアラート連動させたかったのにな…。

海外のGrafanaのAlertについてのコミュニティのスレッド見ても荒れてます(^^;

 

うーん、当初の監視と運用の悩みがここにも出てきてしまいました。

どうしましょ( ゚ ρ ゚ )

PrometheusでBlackbox expoterを使ってノード遅延をGrafanaで感じよく?

Grafanaが出てきた時点である程度想像がついたと思いますが、今回はPrometheusを使って監視環境を作っていきます。

まぁ、PrometheusやGrafanaは、特段私があれこれ言うよりも先人の方々のブログのほうが面白いかもです。何故なら今回は愚痴ぽい内容だからです(^^;

f:id:hunter1014:20190921004456p:plain

とりあえずの完成形を載せますが・・・まだチューニングしきれていないというか、気持ち悪くて納得していないというか・・・。

今回はヨーロッパ各サイトをAzure西ヨーロッパリージョンから監視していくよという内容です。

Azure西ヨーロッパにサーバーをこしらえているので、そこからの遅延を見てみたく、Azure上にWindows Serverインスタンスを起こして、PrometheusとBlackbox Expoterを仕掛けて、そのデータをGrafanaで見るという流れです。

しかし・・・Windows Serverでやってしまったからかな・・・?!

 

なーんか変。

 

オランダ向けと、ドイツ向けのICMPの遅延の値がどーにもしっくりと一致しないのです。それ以外のサイトはなんだかんだで許容範囲内にあるかなぁ・・・という感じです。

ドイツ向けも本来は17ms付近なはずなんですが、2msってなんなんでしょ。

あと、Blackbox_expoterでプローブの取得値をどうとるのかがよくわからず、

f:id:hunter1014:20190921011002p:plain

こんな感じで取り出ししていますが、

f:id:hunter1014:20190921011044p:plain

これも近似値でとれるんですよ。うーん、どっちが正解なんでしょう?

 

でも、どっちで取っても、異常値は異常値なんですよ・・・orz

 

Sclapeのタイミングを5s,10s,15s,20sとやってみたけど、特段大きく変わらず。
あ、でも15s以降のほうがロスト率は下がるかな?

いっそのことN/Aだったり0msとか割り切れればいいんだけど、中途半端に応答してきているんです。これがICMPの厄介な所なんでしょうか…。

結局、ICMP部分で使えるのはステータス情報だけかな・・・?(^^;

やっぱりインターネット越えなんでSmokePingが恋しくなりますね。

 

何処かのPrometheus使いの会社さんが、SmokePingは移行しきれていないようだったので、もしかしたら・・・このBlackboxの挙動に悩まされたからなのかな?

うーん、でもまだLinux系で試していないので、Windowsでの作法がよくないだけかもしれない?

 

ダッシュボード集にあるpingなちゃらとかを色々眺めてみましたが、式がよくわからんのも多く、とにかく何やるにしても苦労しますね・・・。なんでこれ流行っているんだろう(?-?;

 

監視も分析も同時にできればいいのになぁと思いながらも試行錯誤をしていますが、

監視をする画面と分析する画面は別々の方がいいかな?

まだGrafanaのプラグインに手を出していない事もあり、まだ未知な部分ばかりですが、とにかく時間食いまくるなぁ・・・。

ちゃんと教本を読まないとだけかな?(^^;

 

追記>やり方変えたっす!

(直リンクやGoogleでここにいきなり来た方は以下のリンクをどうぞ)

blog.sidetech.jp

GrafanaでAzure Monitorを見てみる

あんまり例がないようなので?

f:id:hunter1014:20190918231634p:plain

Azure MonitorのデータをGrafanaで直接見ることが出来ます。

Azureの管理画面で見ればええやんってのもありますが、自分が欲しい時間帯のメトリックだけを表示させたい・・・とかには標準品では役不足です。

 

いやいや、Grafanaって何?っていう人は・・・

grafana.com

で、少し調べてくださいませ。カックイイ感じのグラフをグリグリやれるヤツです。

 

てことで、最近流行り?のGrafanaで何処までできるのか、ちょっと試してみた系です。まだ凝ったことまでは出来ないです・・・勉強時間が足りない・・・。

私が試している環境は”Grafana v6.3.5(67bad72)"で、Windows Serverにインストールしているものになります。

 

Azure Monitorとどのように連携するのかは・・・

qiita.com

こちらを読んでいただければ、なんとなくできます。

 

Grafanaは、ダッシュボードという公式の物とコミュニティの物を使ってある程度、グラフの汎用品を利用することが可能です。もちろん1から頑張ることも可能です。

https://grafana.com/grafana/dashboards

この中からAzureに使えそうなのをピックアップするんですが、これがまた結構な確率でそのまま動かない(苦笑)。

ただ、Grafana学習の最短距離は、数々の有志が作成したダッシュボードを解析することが理解の近道のような気がします。

 

て・・・事で・・・完成しました。

f:id:hunter1014:20190918232809p:plain

なんとなくシュッと出来たかな?まだ細かい単位的な部分は怪しい所もあります。

世間のサンプルだと、中々”Variables"の設定をしてという参考例が少ないと思うので、そこも少し紹介します。GrafanaはVariablesを駆使出来ないともったいないですよね。

でも中々自分が思うサンプルがなくて苦労する部分でもありますね…(^^;

 

今回は、Variablesを利用して、リソースグループの選択と、リソースネーム(vm)の選択ができるようにしました。内部ではネームスペースは固定にしています。

f:id:hunter1014:20190918233549p:plain

ネームスペースは”Microsoft.Compute/virtualMachines"を使っています。
ネームスペースで何のメトリックが取れるかは・・・

docs.microsoft.com

こちらでご確認ください。

ただーし・・・

f:id:hunter1014:20190918233914p:plain

私の努力不足なのか、拾えそうなのは上記の通り。
おそらくリソースグループを軸にしてしまっているからかな?!?!
ちょっとまだよくわかっていないです。Grafanaがどこまでできるのか、もっとできる子なはずです。

 

f:id:hunter1014:20190918234044p:plain

てことで、Variablesの設定内容です。これね・・・この画面だけじゃ詳しい設定内容が分からないんですよね・・・。

一応、参考で載せます。正解かどうかの保証はしません!

f:id:hunter1014:20190918234612p:plain

取得値が間違っていなければPreviewに欲しい情報が表示されるので、ここを見ながらセッティングする感じですね。あと先にVariables済みじゃないと式が使えなくなるので、順番も大事みたいです。

f:id:hunter1014:20190918234751p:plain

f:id:hunter1014:20190918234802p:plain

こんな感じで今回は設定しました。

しかしこの方法では弱点が1つあるっす。後ほど説明します。

まずはどうしてこいうしたかですが・・・参考にしていたダッシュボードのデータを見ていたからかもしれませんが・・・

f:id:hunter1014:20190918234927p:plain

クエリーにAzure Monitorを選ぶと、上記のような項目が最初からセットされるんですよ。。。なので必然と・・・こうなった・・・という感じです。

 

しかし、ネームスペースの条件を変更すると・・・

f:id:hunter1014:20190918235158p:plain

AzureVMのネットワークインターフェースってバインド型?なので、VMと紐づけて・・・という表現がちょっとスグに思いつかなかった。。。orz

 

他にもpublicIPAddressというのもあって、これはDDoSのパラメータとかも取れるようで面白そうなんですけど・・・VMマッピングするにはVariablesで計算式を考えないといけないんで・・・f:id:hunter1014:20190918235333p:plain

今回はパス!!


てことで「Microsoft.Compute / virtualMachines」のメトリックだけいけそうなやつをまとめた感じですが・・・

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported#microsoftcomputevirtualmachines

 

ぱっと見は良いんですが…
コレジャナイ感半端ないです・・・Orz

これなら、まだAzure インサイトで見たほうがいいかな…。

この取得したデータからはディスクのI/Oに対する危機感は持てますが、例えばディスク使用量が分からんす。ネットワークもピンと来にくい。最近のMiBとかGiB表現も好きじゃないですが、Bytesじゃグッと来ないですね。困った(^^;

 

Grafanaで困るのは、取得データの単位をどうするべという所と、CurrentなのかMaxなのかMinなのかAveなのかを取得時と表示時に考えなければならないです。

取得方法によっては、計算式を使って加工ができます・・・がAzure Monitorでの連携取得の場合、どこに計算を落とすのかがちょっとピンとこなかったです。

もっと他にとれるデータがあればいいんですけど。。。

Azure インサイトのデータが欲しいですね。そうすれば、Prometheusのwmi_exporterとか使わずに済むんですが。Agentがすでに4つぐらいぶち込んでいるので突っ込みたくないなぁ・・・もうちょっとお勉強が必要そうです。

 

Azureで次世代の監視(インサイト)

ご無沙汰のこんちゃーす。すっかりブロガーと言うことを忘れておりました。

久々の投稿になります。

f:id:hunter1014:20190916210218p:plain

今年、実は3度目の海外出張です。カナダ(トロント)、韓国、そして今回ベルギーです。
今回は滞在期間が長く、9月はほぼベルギーに居ます。

仕事はだいぶバーチャルな仕事をしているはずなのですが、やはり現地側にいたほうがクイックに対応できる部分もあり、時差もしかりでベルギーに滞在しています。

旅の報告はまた次回として、今回は「Azure Insight」です。

 

カナダに居た時も便利だなぁとおもっていたんですが、今回も「Azureインサイト」によって通信不良といいますか、不具合をキャッチ出来たんで、ちょっとご紹介。

監視というと、死活監視とSNMP監視、ほかにアプリケーション監視にログ監視・・・・色々ありますね。

最近ではクラウド系監視なんて言葉が出てきたり、SRE(Site Reliability Engineering)なんて言葉が出てきたりで、運用の在り方うんぬんの流れも変わっていている模様。まぁそんな小難しいのは他人に任せて・・・と。

 

先日、とあるお方に愚痴をこぼしたんですよ。そしたら、その中での答えに”死活監視”と”性能監視”は分けるべきだよと。そのトーリなんですけどね。

で、今回はおそらく性能監視的な方向性の一部の話になるかと思います。

性能監視のうんぬんかんぬんも奥が深いので、今回の記事では割愛。

 

今回はですね、フローの監視に近いのかな?でもアプリケーション寄り。

Azureには、とりあえず監視という項目に

インサイト

「警告」

「メトリック」

「診断設定」

「アドバイザーのレコメンデーション」

「ログ」

「接続モニター」

というのがあり、更にトラブルシューティング向けになっていますが、

「リソース正常性」

「ブート診断」

「Performance Diagnostics」

てのがあります。今回は「インサイト」にフォーカスします。

 

今までの監視で、サーバーからプリンター出力しようとした場合のログってどこから取れますか?どの様に取りますか?

おそらく、監視対象にはならないと思います。必要な時にパケットキャプチャしたり、netstatで見たりはするかもですね。

そしておそらく、1度でも正常に処理できていれば後は気にしないフローになりますよね。

まぁ、どこまで気にするかにもよるかもしれませんが、実体験としてリフト&シフトの際にはこれ、結構役立つのではと思った次第です。

 

さて、以下は実際にあったケースですが、参考例としてみてくださいね。

f:id:hunter1014:20190916212331p:plain

サーバーはターミナルサーバーです。28のクライアントから接続があり、1つだけ赤の点線がでています。タイムレンジは最新から30分という状況です。Port443で何か通信ミスが出ている様子です。

 

f:id:hunter1014:20190916212549p:plain

Port443をドリルダウンすると、4つ通信エラーが出ているのが確認できました。うーん、これだけだと、何故かが分かりずらいですね。1つ選択してみた所、ソースプロセルがWINWORDがFailedしているという情報が出てきました。

WORDでautodiscoverとなると、勘が良い人だとここでもう答えが出るようですが、

ここで、ソースプロセスを探してみましょう。

 

f:id:hunter1014:20190916213355p:plain

サーバーに55プロセスが動いているということで、こちらをドリルダウンしてみます。

どうやらMicrosoft Officeプロセスに通信エラーが出ているように見えます。

この時点で、どのプロセスからというのが直ぐに分かるのが良いところですね。

 

f:id:hunter1014:20190916213545p:plain

そして、Microoft Officeを展開してみると、なんとEXCELも通信エラーの対象になっていました。

 

プロセスで確認出来るってのがすごいすね。で、そのプロセスのユーザーネームが表示されています。今回はログインの方法が少しアレンジされており、そこを修正しないとエラーが出ることが分かっていたのですが、まさか可視出来るとは。

 

こんなかんじで、プリンターの何処が繋がらないとかのチェックやら、リフト&シフト時にありがちなのですが、修正プログラムの宛先が、何故かまだオンプレミスを指しているとかあるので、インフラ屋はプログラマの通信先のミス経路(修正漏れ)についてお知らせすることが出来ます。

 

様々なトラフィックをBandwith(帯域)で見るだけでなく、アプリケーション可視化で見れてドリルダウンできるようなグラフだと良いんでしょうけど、中々骨折れますよね。キャプチャにはいれていないですが、各プロセスが必要としたネットワークトラフィックもグラフで一応表示されます。ちょっとピンときにくいグラフだったので割愛しました。

 

実際に、この後に閾値の設定やらとファンクションはあるんですけど、そろそろ自己学習的なものって出てこないですかね。

正しいか正しくないかを教え込むのは大変そうですが。

一応、これまでもフロー解析というのはあるにはありました。しかし扱いやすいかは( ^ω^)・・・。

あとは、このインサイトを設定した同士のフローとか相関がどのように見えていくようになるかに期待でしょうか。

正直、いっくらPrometheusとかでデータを取りまくっても、どうやってそのデータを生かせばよいのかというストラクチャを構築するのは途方もない作業です。

というか、今回の様な表現はちょっと出来ないすね。

ただ、インサイトのパフォーマンスグラフはちょっと物足りないですよね。組み合わせ自由度があるようでないようで。まぁそこはデータは取ってあるからあとは煮るなり焼くなりしろってことなんでしょうけど。

 

まあWindowsならではな部分ではありますが、クラウド的な監視だなと感じた次第です。

てことで久々の投稿はこの辺で。

 

ネットワーク屋でもIoTの勉強(番外)-想定外?編

IoTトイレ・・・実際にリアルに動かしてみると、色々な課題点が見えてきますね。

すみません、次の記事が書けていなくて。画面キャプチャーが増えると大変になるのと、社内教育への再利用も考えているので中々(^^;

 

f:id:hunter1014:20180413202440p:plain

若干ミテクレを変えていますが、かなり発展途上中です。スマフォ用ちゃんと考えなくちゃ( ^ω^)・・・。

んで、実環境テストに移してから見えてきた課題点や問題点もチラホラ出てきました。

 

・上記の画像より

空室時間と経過時間を見る限り、19時台にトイレの利用があったはずなのに、記録されていません。

データを見たら、「空室フラグ」が2連続になっていました。

よくよく見ると、「満室フラグ」も2連続がありました…。

私の想定した仕様ではイレギュラーです。うーん。

空室(ドアオープン)が2連続になってしまう理由は直ぐに想像ついたのですが、使用中(ドアクローズ)が2連続はレアケースの想像範囲になります。

何が言いたいかというと・・・

用を済ませた方が、データ送信が終わる前に行動を起こした場合です。

現在、WiFiの接続に何十秒か必要なので、それが条件によって調子悪いのか・・・な。

このWiFi接続の不具合は2.4.0-rc2にどうやらあるようなので、やはり2.4.1にあげる方法を考える必要が出てきました。

他にもバグかもしれないというのもあるか。

ドアを閉めたけどすぐにドアを開けられてしまうと、リードスイッチの情報がオープンの情報として通信してしまうので、これが一つ悪さをしている気がします。

ドアの開閉の時間とWiFiの接続時間の改善はしないといけないですね・・・。

あとは、リードスイッチとマグネットの位置関係がナーバス過ぎるか・・・ですかね。

2連続、同じフラグ情報だったらどうするか・・・という処理を入れておかないと駄目かなぁ…。もう少し発生条件が絞り込めないと駄目っすね。。。

ここら辺はモノづくりな方々は当たり前の苦労なんでしょうね・・・m(_ _)m

 

あとは、今回は、リードスイッチの1か0かを毎回記録しているので、利用時間の割り出しのSQL文がどうしたらいいのか悩んでいるぐらいですかね…(汗)。

SQL初心者にはかなり厳しい構文になりそうです。

時間別集計も構文考えるのに結構苦労しましたが・・・これが沢山のデバイスが繋がってくるとなると…もっと表現を考えねばならないので、色々なSQL文を考えないとですね(涙)。

 

しかしやってみて面白いのは、そもそも使用中によく遭遇するから状況を知りたいと思ったんですが、そんなに時間帯での利用がないんすね。。。
人によっては20分以上籠られている方も居たのが分かったので、占有時間の問題かな?とか思ったんですが、そーすると、MIN/AVE/MAXな利用時間が調べたくなってきますよね。

でもそれを調べても、結局籠る方は籠ると思うんです。何時使用可になるのか・・・。
でもでもそこから先は「誰が」というような符号も増えてしまいそうでプライバシー的に踏み込めないですよね。

AIに?学習させるにしても誰がとかの情報が無いと厳しいだろうし・・・

時間帯的な利用時間のアベレージを出せばよいのかな?遠からず、ある程度時間傾向がでるルーティン族が多ければですが・・・。

 

あとは・・・予兆検知?!
予兆検知だと、モーションセンサーと収音マイク?が必要?!

水が流れる音とかパンツ履いてる音とか・・・(こわっ)

で、インジゲーターには「もうすぐ」とか表示されたり・・・(激汗)。

 

今後これにAI的要素を加えるとしたら・・・なんでしょうね。
気温・天気・湿度?条件付与とか・・・シーズン的な?とかですかね。

打合せ・会議とかのスケジュール情報とか?

それにより混みそうな予兆とか?

 

トイレIoTは奥が深いですね…ヘンタイになりそうです(汗)。

って、私何処までこれ踏み込んでいくんだろう・・・悩みの大半はSQL構文なんですけどぉ(涙)。

想定外の脱線内容になりましたのでここら辺で(笑)

なんとか完成?

なんとか・・・自作なIoTトイレ「スマートトイレ?」は予定の形まで出来ました・・・(手作り感がヤバイ)。

順序立てて記事書きたいのですが、あそこまで書いた以上完成させねばと・・・四苦八苦しておりました。

結局SQLの構文が大変だった・・・というか分かってない(^^;

f:id:hunter1014:20180410201341p:plain

まぁ勢いで作った割には動いている方じゃないかと。

いろいろ嵌らずに、ここまでのクオリティで良ければ1~2日分の時間で行けそうですが、土曜からチョイチョイ初めて、火曜にはここまで出来てるんだから、そら世の中色々早く生まれてくるわけっすね。

 

ただ、ここからのアレンジが大変かな・・・。

久々にPHPに触れて・・・まず色々忘れていたのと、SQLも複雑なのを書いた記憶がなく、書いていた記憶も約18年前・・・(^^;

HTMLも約18年前の知識をフル活用

今時も分からなければCSSも分からないんでシンプルなページしか作れないという。

 

でもよくわかった。色々あるけどキモはSQL(汗)

次の記事は纏めたら投稿しますm(_ _)m

参考にしたサイトが多すぎて、どれが助けになったのか・・・まとめねば・・・。
とりあえず初級編は突破出来ました報告ということで。

ネットワーク屋でもIoTの勉強(2)-環境準備編

今回は土日でやっつけている範囲がボチボチ多いので…ブログもかなり細切れです。

ということで、買い物準備は終わったので、環境準備です。

買い物が終わるとね・・・ちょっと寂しいですが、ここからが上り坂!

まずは・・・

Arduino - Donate :ここからArduino Softwareを入手して・・・(私は1.8.5)

esp_dev_arduino_ide – スイッチサイエンス でESP8266対応して・・・

で、ここでなのですが、ESP8266 Community のバージョンが2.4.1が出ているんですが、コンパイルエラーが出るので、2.4.0-rc2を私は使いました。

 

で、とりあえず、この段階で「Lチカ」をやっておきましょう。

とはいってもですね、

ESP-DOOR – スイッチサイエンス

上記の「動作確認用簡易サンプルスケッチ」をやればおkです。

サンプルスケッチに出てくる

>int LED = 4;
>int reed_sw = 5;

ですが、I/Oのピン番号を指しています。

で、Door Sensorは出来合いモノです。埋め込まれたLEDと最初からついているリードスイッチはすでにピンを消費しています。

なので、色々検索すると「ESP8266」や「ESP-WROOM-02」というのを使った例がでてくるのですが、それらともちょっと違う実装済みな部分があることに注意です。

コピペでやってみた系の方々でハマる最初のポイントになりますので・・・。

読み替え技術を備えるチャンスでもありますw

ということで、上記のintパラメータを見ながら

 

>pinMode(LED,OUTPUT);

これはI/OのpinモードをOUTPUT(出力)にセットしてます。LEDを光らせたいのでOUTPUTです。LEDは4番ピン配置なので、4番ピンをアウトプットに設定の意ですね。

 

>digitalRead(reed_sw)

これは、デジタルモードでリード(読み出し)するってことで、I/Oの5番の状態を0か1かを知りたいという命令ですね。

 

>digitalWrite(LED,HIGH);

>digitalWrite(LED,LOW); 

これは、HIGHがオンでLOWがオフで、I/Oの4番ポートにデジタル的出力をかますコマンドです。ここが皆さん大好きなLチカの部分になってきます。

 

今回のESP Door Sensorを使う場合は、他のプログラムのコピペをやる際でも、読み替えが必要な部分となるのでお気を付けください。

これわすれちゃうと、LEDが光らないとか言い出しますからね。

 

さらに実用サンプルスケッチも入手できますが、このサンプルではAzure IoT Hubと仲良くできません。

ESP.deepSleep(0, WAKE_RF_DEFAULT);

使いたいのはこれぐらいですかね。

大まかな流れは同じなのですが、HTTPでアクセスする部分が想定と違うのですが、この実用サンプルをベースにするよりはAzure IoT Hubをやられた方のサンプルスケッチをベースにした方が今回はラクチンでしたので、抽出するポイントだけ書きました。

 

さて、本丸?ですが・・・

こちらの記事で、私が伝えたいことはほぼ完ぺきですw

こちらの記事の「デバイスの設定」の所に「AzureIoTHubライブラリー」てのがありますので、記事通りにやっていただければ・・・(汗)

 

Azureの部分の説明もしっかりされているので出る幕はないんですけどね・・・。

このライブラリーがあるお陰で、私はだいぶ想定よりも楽出来ました♪

 

環境準備といいながら、この記事でコンプリートなんだけどな・・・。

どこをアレンジしたかは次回に。

ネットワーク屋でもIoTの勉強(1)-部材調達編

ということで”トイレIoT勉強”の続きです。

さて、組めても組めなくてもモノを買うときって何故か楽しいですよね。買って満足的な。人生でどれだけそーいう事があったことやら。ダイエットアイテムを買ってダイエット取り組み決意した感じと似ていますね。

まぁまぁまぁ。今回は主役であり、わき役でもあるので多くを(自分に)望みすぎないで行きましょう。
てことで「部材調達編」です。

欲求を叶えるために必要なモノを探していけばいいですね。
ここで大事なのは「割り切り」と「工夫」です。

Arduinoを収める箱が売っていないかを探しても見つからず途方にくれたり、「3Dプリンターで作る」とか大きく出たりしなくてよいです。カッコつけは後から考えましょう。でも今は昔よりも強い味方がいます。アイデア次第で目的と違った使い方が出来ますからね。既製品好きやブランド志向の人にはキツイかもね・・・。

想定してるのは、トイレのドアで、使用されていないときは、ドアが開く環境のものですね。もしもドアが閉まってしまうタイプだと、もういっちょ人感センサー的なのが必要になりそうです。

f:id:hunter1014:20180408172628p:plain

まずはArduinoなヤツからです。とにかく通信手段付きで、半田も使わずに苦労せずに実現できるものを探したらですね・・・さすがswitch scienceさん。

 

[スイッチサイエンス] ESPr® Door Sensor

[スイッチサイエンス] ESPr® Door Sensor

 

 狙ったでしょ?というような商品を開発販売していました。
長細い赤い部分が、リードスイッチになっているところで、磁石でスイッチが入る仕組みです。

さらなる狙いが消費を抑えてバッテリーでもロングランできるようにというのが狙いのようですが、その部分の考え方は私は今回は別の部分で使おうと思います。

しかし・・・このリードスイッチ付きのものは・・・ほかに何に応用できるかな。

[スイッチサイエンス] FTDI USBシリアル変換アダプター Rev.2

[スイッチサイエンス] FTDI USBシリアル変換アダプター Rev.2

 

さらにUSBシリアル通信させるアダプターも今回は購入です。プログラムを書き込むのに必要になるんで。

 

あとは、マグネットを買わねばーなのですが・・・

f:id:hunter1014:20180408173924p:plain

 まぁ磁石なら、なんでもいいんでしょうけど・・・ある程度の成形品で安いやつをね。最初から両面テープついているし。リードスイッチだけ位置をずらさねばならんかもしれないしと。すこし入荷に時間が掛った気がしますが・・・ま、ここは好みで。

 

f:id:hunter1014:20180408174028p:plain

あとは、100円均一の力を借ります。ヘアピンの入れ物とか画鋲の箱とか、何気ないケースが電子工作では使えたりします。電源も5Vが欲しいUSBと同じでよいという考えで、アダプタも昔よりも悩まなくなりましたね。MicroUSBもとりあえずだし。

ヘアピンの中身は娘か会社の女子にでもあげちゃってください・・・。

 

で、全部でいくらぐらいかな・・・(金額はかわるかもしれないので注意)。

[SWITCHSCIENCE]ESPr® Door Sensor ¥2,700
[SWITCHSCIENCE]FTDI USBシリアル変換アダプター Rev.2 ¥1,080
[SODIAL]ホワイトドア窓コンタクト磁気リードスイッチセンサー ¥249
[DAISO]USB充電ACアダプタ アンドロイドスマートフォン ¥200
[DAISO]USB-MicroB スマートフォン用急速充電専用ケーブル50cm ¥100
[DAISO]Hair Pin アメリカンピン約40g(ケース用として) ¥100
[DAISO]しっかり晴れてきれいにはがせる両面テープSサイズ8枚入り ¥100
合計 ¥4,529

 こんな感じですね。

2か所目からは大体¥3450ぐらいと思っておけばいいですね。

USB-MicroBが50cmしかないので、これはDAISOではなく、長くて安いのを別途調達した方がよいですね。

3mで500円とかあるんですね。ネットで何でもそろう時代ってすごいわぁ。

 

全体感でいうとDoor SensorなArduinoが一番お高いですね。ESP-WROOM-02が使いたいだけなので、もう少し安くできるかもですが、ハンダを一切しないでという条件からそれてしまいます。

両面テープも3Mのやつにした方がよいと思いますが、まずはということで。

 

これで20か所設置するようなことになっても大した金額にはならんで済みます。

問題はWiFi環境という意味で・・・トイレに電波が届いているかが最大の課題になりそうです。。。(汗)

 

とりあえず、どんな感じで動いたかだけ…。

f:id:hunter1014:20180408185019g:plain

LED点滅時はWiFiコネクションを頑張っています。

2秒のLED点灯はAzure IoT Hubにデータを送ってます。

今の所、リードスイッチがONになる時とOFFになる時に、WiFiに接続してAzure IoT Hubにデータを送った後、DEEP SLEEPさせてます。
DEEP SKEEPからの回復条件がリードスイッチの挙動で、その時に改めてWiFiの接続を行ってます。

プログラムの作りが甘いので、WiFiのコネクションが上手くいかないとずっと繰り返し施行するようになっています(^^;

Azure IoT Hubへの送信ですが、どうやら2秒程度待ってあげないと、データの送信が終わる前にDEEP SLEEPモードに入ってしまうような状況だったので、2秒間LEDを付けて、データ送信している風を演じていますw

 

ここまで動かすのに、2名から3名程度のブログ記事を参考にして、プログラムをミックスさせて動かしました。なのでパクリだけでAzure IoTとやり取りできました(汗

プログラムソース公開をためらう程、パクリなので悩んでいます(^^;

 

次回からいよいよ

・ESP8266の参考とパクリ改変ポイント

・Azure IoT Hubの参考文献ととりあえずやっちゃえの部分

・Azure Analyticsの参考ととりあえず動かしちゃえの部分

・Azure AnalyticsからとりまBLOBにJSONで格納の部分

ここまで、基本的に参考サイトのコピペになりそうなので、ちょっと悩みます(^^; 

ネットワーク屋でもIoTの勉強(0)-欲求定義編

前に土日を使ってArduinoの勉強をしていたんだけど、ちょっと間が空きすぎたというか、少し端折って行きたい事情が生まれまして・・・あんまり良いやり方ではないかもしれないけど、とにかく『IoT ready な俺』してみようと急遽始めました。

 

発端は同僚と飲んでいる時の事だったんですが、お酒を飲むとトイレがそこそこ近くなるのですが、まぁ例のごとく待たされるわけですね。

トイレの待ち時間がイラつくと。

「そーいあ、会社でもトイレが埋まっていて、別のトイレにいっても埋まっていると・・・ギリの時はヤバい」

こんな話、IT界隈のIoTをやっている人なら色々情報が溢れているし?IoTトイレで商売を始めちゃうキャリアさんも居るので、皆さんご存知じゃないかと。

何年前?2年前?IoTトイレブームって。

でも、世の中ちょっと馬鹿にしている部分があるようで、IoTトイレの普及率はイマイチな感じがします。

まぁあんなにお金を掛けてできないよねぇ...( = =) トオイメ目

でも今回、後後発ですが、やってみます「トイレIoT」

 

で、元々?ArduinoRaspberry Piを触りだしていた私、最近AWSよりもAzureの速習が忙しく、Azureの勉強中ではあるものの、基本的にネットワークと仮想マシンの部分とVPNを張るぐらいしかやっていないんですよね。IaaS領域ばかりで他サービスって使ったことなかった。

まぁプログラムは苦手だけど、ネットワーク屋さんでもどこまでいけるかやってみますか。。。いい感じの所までいけちゃえば、最悪アプリ屋に引き継いじゃえばいいかとw

あとは、上手くいけば入門教材ぽく出来るんじゃないかなと思いまして。

 

だってサーバーレス時代?それって他人のふんどしつかってやるってことっしょ。

だったらとことん他人様にご厄介になって、コピペでいいから動かしてみるか。。。

 

と、なりました(^^;

 

さて、じゃぁさ・・・ある程度は基本理想を立てて、完成モデルと暫定モデルを考えて、理想と現実上手くあわせてやっていきましょうと。
さて、前置きが長かったですが、「欲求定義編」です。

 

f:id:hunter1014:20180408164752p:plain

と、いうことで、欲求に沿った基本的な方針と流れは・・・

・なるべくサーバーレスで今どきっぽいのを活用

・楽する部分はとことん楽をする

・先輩方のライブラリを探して流用する(結構学生さんのやつが役立つ…)

・コストは可能な限り掛けない

・余計な時間を掛けすぎない(本来の目的からの脱線時間が長いときつい)

 

で、覚えなくちゃならないことだらけなんだけど・・・模範解答を徹底活用w

この中で私が一番苦しくなると思ったのが「web app」のあたり。

従来のApache+PHPSQLなら私も簡易レベルであればなんとかできるんですが、サーバーレスの理想でいうと、node.jsとかに行く方がいいのかな。。。最近JSONだのなんだとjsばかりよね。ちょっとそこを深堀するには時間キツイかもなぁ。

まぁとにかくデータの格納までしてしまえば後はどうにかなるだろうと。

で、上記の要件を叶えるため・・・

arduino(のESP-WROOM-02を使う、安い、そこそこ例がある)

・Azure IoT Hub(を使ってIoTした気分になる。Deviceから直接サーバーは勉強にならなくなるのであえて使う)

・Azure Stream Analyticsを使う。将来的にINとOUTの柔軟性確保。

SQL DatabaseとBLOBとcosmos DB<Nosql>にぶっこんでみる(よくわからないJSONの勉強になるはず)

JSONの使い方をおぼえきれなくてもMS-SQLにさえはいっていれば後はなんとかできるはず

 

きっと色々苦労はあるけど、2日間でどこまでいけるか。

てことで先にハードウェア面だけネタばらし。

f:id:hunter1014:20180408170240p:plain

最小限でしか盛り込んでいないけど、なんとか今必要な機能は達成。

設置場所でWiFiの電波が取れなかった場合についての別の手段を考えるのを忘れたぐらい。あとは、会社のトイレは未使用時はトイレのドアが開いていますが、多目的トイレなどでは扉がしまりっぱなので、その場合にはこれは使えないなと思うぐらい。

 

ここまで完成させたときに思ったこと。

『においセンサーとか他にもセンサーを付けてみたいなぁ』

ま、それは追々ね。

Cisco Meraki vMX100 仮想アプライアンスで楽してみた。

Azureネタが続きます。

やっと、念願?のMeraki vMX100を動かす時が来ました。

AzureでVPNする方法はいくつかあるのですが、その用意されたVPNゲートウェイを使わずに仮想アプライアンスゲートウェイに走るという・・・なんだか手抜きな仕事に感じます(激汗)。


まだAzureをまともに触りだして1カ月経ちませんが、勢いで組んでみたいと思います。

f:id:hunter1014:20180330193445p:plain

Meraki vMX100はライセンス購入のみで、ハードウェア費用にあたる部分は特にありません。AWSもAzureもそこら辺に違いはありません。

画像の通り、Internetポートだけオンラインになっていますね。コンセントレーターモードで動くという事らしいです。

 

セットアップについての・・・

vMX100 Setup Guide for Microsoft Azure - Cisco Meraki

参考情報はこれぐらいです(汗)。

細かいAzureでのデプロイとかトークンキーとかの部分は割愛します。

f:id:hunter1014:20180330193807p:plain

Site-to-Siteの設定が終わると、いつもの?感じ?で眺められます。

しかしAutoVPNの威力はスゴイ。相変わらずVPNを設定している感覚はありません。

赤い部分がちょっと長いですが、途中で中断して他の仕事したりだったんで・・・と言訳しておきます。
おまけに余計なVPN通信をしない様にもう少しVPNターゲットを絞っておきたいですね。

 

f:id:hunter1014:20180330194046p:plain

ちょっとポイントとしては、赤枠の所ですね。Localネットワークの部分を自分で明示的に入力する必要があるということぐらいです。

本来はLANポートがあってVLANの設定とかポートアサインとかネットワークセグメントを設定してある状態なので、その設定情報に対してVPNに通すか通さないかの設定をするだけなのですが、Azure側がルーティングのキモを握っているということもあり、明示的にする必要が出たという感じですね。

 

f:id:hunter1014:20180330194809p:plain

Azure側もチラリと。vMX100をデプロイすると、勝手に変なリソースグループを作成しやがります。ただ、ルート情報は、デプロイ時に作成したリソースグループを使うようです。

 

f:id:hunter1014:20180330195028p:plain

変な文字羅列付きの方に仮想マシンとか仮想ネットワークとかが展開されていますが、リードオンリーのリソースグループになっていました。

 

ルートテーブルに、他の拠点のネットワークセグメントの情報を書き出して行く感じですね。

今回は米国東にデプロイしています。日本との遅延は237msでした。うーん、思ったよりもありますね・・・。200ms以下だったらよかったのに。カナダのトロントが245msぐらい掛かるので、多少は良いというぐらいですね。まぁ日本からメインで使うわけではないので、今回は良しとします。

 

アメリカで何拠点か、このAzureへアクセスする必要があるのですが、既にセットアップ済みなので、MXをオンラインにしたら自動的にAzureにもつながると・・・。

 

いやぁ・・・手抜きな感じだなぁ・・・楽すぎる・・・。
Merakiに限らず、AWSやAzureのアプライアンスマーケットには色々な機器があるからね、みんなこんな感じなのかな?


Meraki MX使いの方でAWSやAzureを使う人でBGPが対応していないし~って嘆いていた人には良いかもしれないです。

(現在BGPはBetaプレビューとの噂も聞きましたが・・・)

Meraki vMX100の可用性については次回?!にでも。。。

Azure本を読んでも分からんから実践3(vNet-準備編)

多分ね、AWSもAzureもvNet(VPC)[仮想ネットワーク]から始めるべきっすね。。。アレコレやりたいと考えるならば。

取りあえずの手始めに、サーバーをさくっと建てて「ほら、簡単でしよ?」というのは反則に近いですね・・・AWSもAzureも。

分かりやすさの玄関なのかもしれませんが、1m進んだら深海に落ちるって誰か、ちゃんと説明していますかね…(^^;

仮想マシンのデプロイでも少し?ほにゃららで良くわからないのを無視してもとりあえず動きますが、ちゃんとデザインを考えると、事前知識がどれだけ必要なのよ…という状況です。。。

今回、私の理解が進みだしたのか、何気に本家のドキュメントが読みやすくなってきました。やっと求めている情報と脳内が噛み合い始めたようです。

f:id:hunter1014:20180320140508p:plain

ま、愚痴はこの位にして、Azure初心者な私が疑問に思いハマりそうだという所をピックアップです。

仮想ネットワークを初めになんとかしましょうというのは、

Azureテクノロジ入門 2018

Azureテクノロジ入門 2018

 

 こちらの本にも書かれているのですが、特にこの仮想ネットワークは最初に決めておかないと、後から変更が難しい・・・いあ変更はムリと思ったほうが良いかもです。
その為、ネットワークのサイズが/16とかデカくなっちゃうのでしょうかね。


さて最初の用語ですが、

アドレス空間(CIDR)

・アドレス範囲(Subnet)

という部分がありますが、CIDR「くらすいんたーどめいんるーてぃんぐ」と表記上はなりますが、会社で例えるなら、部署になりますかね。最初、拠点って表現しようと思ったんだけど、それはリージョンだなと。で、Subnetは課にあたりますかね。

この表現も適切に感じないなぁ・・・(でも次に進む)。

 

で、アドレス空間の中に「ゲートウェイサブネット」は1つ持てます。

急にゲートウェイサブネットって出てきたね。

Azureでは、Site対SiteのVPNやExpressRootを使う場合はサブネットゲートウェイを使いなさいという作法になっています。オンプレのVPN機器とIPSecで結んだりBGP使って繋いだりする部分ですね。

なので、VPNを組む予定がある場合は、ゲートウェイサブネットのアドレス範囲を確保(考慮)しておく必要があります。

ここら辺までは、必然とある程度はわかるかもしれない。

ということで先人のページを拝借して・・・・(汗)

ってことなんですよ。(^^;;;

 

でも、仮想マシンを使う「仮想アプライアンス」なファイアウォールルーターが出てくると・・・?これらもゲートウェイサブネットを使うんでしょうか?どうやら無理ポいすね。 仮想はなんでもありな分、作法が色々とうるさいです。

仮想アプライアンスを使うVPNは如何したらよいのかは、各サードパーティー製品の説明に委ねるとして、どうやら、仮想アプライアンス用のDMZ的なサブネットが必要そうです。でないとルーティングに困るようですね。

ムムム、一気に情報量多くなりましたね…(汗)。

 

まぁ、言いたかったことは、使うか使わないか分からないけど将来もしかしたらがあるかもしれない要素を、ほぼ最初の時に定義しておくことで、ある程度報われそうという話です(^^;

てことで、今回言いたいのは、

 

アドレス空間(CDIR)の決定

●仮想アプライアンス等のDMZ-Subnetの確保・決定

ゲートウェイサブネットのSubnet確保・決定(推奨? /27よりおっきく)

・フロントエンドSubnet/バックサイドSubnet/DB Subnet/MGT Subnetなどの決定

 

を、最初の最初でやらねばならないので、使わないと思っていても、ある程度のサブネット範囲を抑えておいた方が良いんじゃないかと思った次第です。事前の理解量も結構必要ね…(^^;

最初の要件になかったとしても、追加要件を食らった場合のお互いの損失を考えるとね・・・( ^ω^;)・・・

 

そろそろ、図を用意しないと駄目ね…。

Azure本を読んでも分からんから実践2(Compute-可用性編)

うーん、AWS知識をカタカナ英語な理解で進めると、やたらと躓きますね…こんにちは。

今回は、可用性な話です。

f:id:hunter1014:20180319154546p:plain

仮想マシンの作成時にすぐに「高可用性」という項目があって「可用性セット」てのが出てきます。これってどうやらデプロイ時にしか選択出来ないようで、後からやっぱりやると言っても駄目そうなんですね。

本来なら、デプロイなんて、するするする~っと出来ないと駄目なのに、実際には「これはなんだあれはなんだ」状態です。そして、あとから修正出来ないとか・・・いあー参ったね。

 

で、Azureでは色々な可用性の話が出てくるんですよ・・・。

仮想マシンの可用性とストレージの可用性・・・
・LRS [Local Redundant Storage] ローカル冗長ストレージ
・GRS [Geo Redundant Storage] 地理的冗長ストレージ

・Manage availability [可用性セット]
・Service Healing [ 仮想マシンの自動復旧]

くっそ~。彼方此方で可用性の話されてシンドイな。

サクッと理解できる方法ないのかなって思うけど、ここに輪を掛けて混乱するのがResourceやらロードバランスとの関係なんだろうな…。

 

とりあえず、やっつけやすい所から。

可用性セットがなしの場合でも、仮想マシンについては「Service Healing」という機能で、ホスト障害があっても別のホストに自動復旧する仕組みが標準であるんだって。

これはvmwareでいうHAな話と一緒だね。なので、自動復旧機能のダウンタイムの許容とセッション断やらデータリカバリが何とかなるなら、可用性セットは気にせんでもいいのかな。

Azure 仮想マシンにおける可用性の考え方 – ainaba's blog
↑のサービス復旧図の解説が分かりやすかった。

 

ただ、AWSとAzureの違いでいうと、AWSの場合は、Availability Zone(以下AZ)というのを指定して仮想マシンを構築するのに対して、Azureの場合はその指定は無し(将来対応するっぽいけど?)。なので、AZ-a,AZ-cに自己配置出来るAWSと違って、Azureの場合はWEBサーバーを2台用意しても同一のゾーンに配置されちゃうかもしれない訳です。
AWSのAZの場合はAZ毎のサブネットを作るので、同じサブネットでの可用性は無い感じに対してAzureの場合はサブネットは同一のものが利用できる感じね。

で、同じサブネット内に例えば2台のサーバーを建てちゃうと、AWS風にいうとAZ-aに配置する感じになっちゃう。これだとSLAが微妙ね?
てことでAzureでは「可用性セット」という考えがあるんだと解釈した(^^;

f:id:hunter1014:20180319163313p:plain

で、AzureではAZの事を「障害ドメイン」ていう表現になるぽいですね。
AWS : Availability Zone
Azure : Availability Domains ? Fault Domains

まぁメンドクサイ。更新ドメインは良いと思いますよ。同一グループの更新を一気にやらないで済む仕組みはいいんじゃない。

高可用性の可用性セットをしたら勝手に仮想マシンの複製が出来るのかと思ってたけどさ、違ってた。

プログラム的にいうと、可用性セットの宣言を行って、パラメータはこんな感じです・・・という流れなのかな。

宣言を行う事で、その可用性セットのグルーピング(障害ドメイン)は0と1に分かれていますね。これがAWSでいうところの、aとかcとかっていうやつですな。

f:id:hunter1014:20180319163326p:plain

こんなパターンも作ってみましたよ。


うーん、今回も結局やってみれば本の言っていることが分かってくるけど、どーにもAWSもAzureもローカライズに問題があるような・・・?大事な言葉はムリに翻訳しなくてイイさ~。

でもこれは色々参ったね。ある程度ちゃんと理解してからでないと設計しにくいぞ。
触っているお陰で前進はしている気はするんだけど、AWSを触り始めた頃よりも苦労している気がする。何が違うんだろう…。


分かっている事は、AWSもAzureも本家サイトの情報が一番わかりづらいのは共通しています :-)
これは英語の言い回しをそのまま翻訳するからなのかな?

 

GRSを活かした構成な設計が出来るようになるまで道のり長そうだ…(^^;

さて、次行ってみよう。

Azure本を読んでも分からんから実践1(Compute編)

最初に触れたのが2016年頃なんですが、結局ネットワーク周りのVPNまでを楽しんで終わっていたので、今回は真面目にAzureを触り始めました。
クラウドサービスという事もあって、画面の雰囲気が変わったり、古い機能と新しい機能が混在していたりして良くわからないなと思っていたのが2017年。

日々進化?するクラウドサービスなので、本記事も書いた瞬間から陳腐化が速いのは分かっちょるです。ただまぁAWSに比べてネットの情報も少ないので、少し書いてみようと思った次第です。

f:id:hunter1014:20180313185420p:plain

今回は、AWSの初心者向けの10分構築流にネットワーク周りの話は抜きで、兎に角サーバーを建てるだけ・・・なんですが、捉えにくい部分にフォーカスします。

今回、対象としたのが、”B2S”というコンピュートノードサイズです。”B1S”でも”B1MS”でも良かったんですが、Windowsって1コアだと色々シンドイもんで・・・。

まずもって、この画面からもAWSと流儀がちがいますね。AWS出身者もクラウドサービス初心者もいきなり勘違いしてつまづくかな?

 

まず、『ローカルSSD』という表現がとっつき難いですよね。これってOSのドライブの事なのでしょうか。それにしては容量が小さすぎです。
AWSもEBSという捉えにくい概念でしたが・・・AzureではEBSにあたる部分は「データディスク」になりますね。

で、「ローカルSSD」ですが、位置付けとしては、”仮想ネットワークストレージディスクではない”ので、ローカルらしいです。ストレージドライブは多少なり遅延がありますが、ローカルなので低遅延という事みたいです。ただしこのローカルSSDは停止とかすると消されちゃうよ・・・ということなので、テンポラリディスクとかWindowsだとページングファイルとかを置く場所になります。ページングファイルを置くという事だけを考えれば、メモリとのバランスをみてサイズ感はWindows慣れしている方は分かりますね。

あと、コンピュートノードの選択の仕方によって、CPUコアの数だけでは測れないIOPS性能の違いが色々でます。ネットワークにも影響があったりするので、どれを選ぶかは本当に難しいですね。

じゃぁ、Cドライブの容量は何時決めるねん?ってなる所で、「管理ディスク」と「非管理ディスク」の話が出てきます。

本や資料を読むと、「管理ディスク」と「非管理ディスク」という用語が出てきます。どうやら「管理ディスク」というのが2017年頃に追加された機能らしく、本にはディスクの管理が簡素化して楽になったんだよっていう内容が書かれています。
これは初めての人にとっては、何が何のことやらですね。簡素化されてんなら非管理なんてやめちゃえと言いたいのですが、そうもいかないようですね。

f:id:hunter1014:20180313191028p:plain

ここで、兎に角その違いを比較すりゃええのかなと思って、test01とtest02というのを作ってみました。
”test01”は管理ディスクで作成したもので、”test02”は非管理ディスクで作成しました。

先に結論をいうと、起動されたWindows2016の中身を見比べてもなんの違いもありませんでした。
しいていうなれば、管理ディスクは「スタンダードディスク(HDD)」と「プレミアムディスク(SSD)」が選べたことぐらいですかね。ストレージのディスクも本当は選べるのかな?

f:id:hunter1014:20180313191655p:plain

↑これが管理ディスクで作成した場合。OS入ってるってのも分かるわ。

 

f:id:hunter1014:20180313191744p:plain

↑これは非管理ディスクでの作成した場合。でもここまでは構築苦労の差はありませんでした・・・。
ちなみにCドライブの容量はどちらも128GBで作っています。

 

f:id:hunter1014:20180313191915p:plain

こんな感じで動いているのが見えて~の、

f:id:hunter1014:20180313192013p:plain

中を見てもフムフムって感じ。あ~English版なの?!っていうツッコミはとりあえず置いておいて、先ほど言った、ローカルSSDは最初からマッピングされています。

f:id:hunter1014:20180313192403p:plain

Ubuntuでも確認した所、ローカルSSDは「/dev/sdb1」の”/mnt"でマウントされていました(こちらは/dev/sda1は30GBで作成)。

 

さて、ここで2台のWindows、微妙に作り方を変えてきた訳ですが、追加のドライブ(ネットワークストレージ)を足してみましょうか。

f:id:hunter1014:20180313193201p:plain

データディスクの追加とやると「管理ディスクの作成」ってのが出てくるので、ディスクサイズとかを決めて、OKってすると、すぐに終わります。

あとはOS側からオンラインにするぐらいです。”ソースの種類”ってなんぞやって思うんですが、今回は無視。

 

非管理ディスクなtest02でデータディスクの追加をやると・・・

f:id:hunter1014:20180313193610p:plain

ちょっと一部の画面をはっしょりましたが、こんな感じで「管理されていないディスクの接続」なんてのが出てきて、ストレージコンテナはどこやねんとか、ストレージアカウント部分やらの設定をして、ストレージBLOBを突っ込むという様な流れになります。ちょっとメンドカッたです。この部分の簡素化なんやな~とやってみてやっとわかりました。ストレージアカウントだというぐらいなので、セキュリティとかの設定も気にしないとまずいかもですね。

ストレージアカウントも既存のを利用したほうがええのか、新規で別々にしたったらええのかちょっとまだよくわからへんです。

いやぁ、管理ディスク使いやす~いね。

あ、でも料金についてはちょいと注意です。

 


ストレージの場合は容量を使った分だけ・・・の課金体系だったと思いますが、

管理ディスクは一定容量毎で幾ら?ってなってますので計算はしやすいと思いますが、気を付けてください。

 

Azureテクノロジ入門 2018

Azureテクノロジ入門 2018

 
Microsoft Azure実践ガイド (impress top gear)

Microsoft Azure実践ガイド (impress top gear)

 

 

やっと本がいうてること分かってきたど・・・(^^;
しかし、リソースグループが無かった頃ってどうやって管理してたんやろ・・・。

AWSでもどのサーバーが何に紐づいているという情報が慣れないと分からないというか、判りにくいというか、idを見間違えるので、タグとかを活用しますが、Azureはリソースグループで見分けは何とかできそうですね。命名法則にも慣れんとですね。

さて、結構単純な流れできてしまいましたが、コンピュートノード構築時には他にもハテナな機能や役割盛りだくさんなので、ハマりそうだな?って思ったらまた書くっす。

Azureの情報は何が本当なのか・・・マヂギレしそう

久々に『イラっ』っときました。

AWSだけじゃなくてAzureもちゃんと理解しておかないとなと取り掛かり始めたのは良かったんですが・・・。
 
どうにも何時頃かわかりませんが、UIやら機能が大変身を遂げたようで・・・。
 
世の中の情報がどれが新しいのかが…サッパシわかんない。。。
 
MSの人に教えてもらったチュートリアルのような資料もですね・・・もう情報古いし。UIがちゃうし・・・。

まぁ読み替えれば良いかと思って進めてもですね・・・違い過ぎてピンときにくい・・・
 
最初は、「東日本」サイトでせっせこ作っていたんです。
んでとりまVPN張ってみよう・・・とYAMAHA RTX1210でトライしていたんです・・・していたんです・・・。
 
なんでか判らないけど、VPN設定でIKEのphase1しかつながらない…orz。phase2が起きない・・・。
色々調べてみると、どうにもYAMAHAさんは動作チェックリストから外れているではないか・・・こないだまでRTX810が居たと思ったんだけどな…ルートベースかポリシーベースか、静的か動的かと・・・色々な情報をまさぐったけど・・・どうにもいう事を聞かん。
そういや、世間の無償期間中のお試しマニュアルは西日本での例が多いな・・・東日本を一旦捨てて西日本でやれば上手く行くんかな・・・と思って、急遽東日本をつぶして西日本へ・・・。しかし、YAMAHA RTX1210は状況変わらず。先人の方々の情報にもみましたが・・・ここでYAMAHAを可愛がる時間がちょっとないもんで、仕方ない・・・
 
手持ちのJuniper SRX100なら行けるやもしれんと、試してみること数時間・・・。
Azurevpn01
やっとこ繋がった・・・。たった1本のVPNのバイパス組むだけでこんなに意味判らんのか・・・。AWSのほうがまだ設定Configサンプルくれるから組みやすいわ・・・。
 
おし、とりあえずやっとここまで来たら、サーバー立てて突っついてみよう。
どれどれ、とりあえずWin2012DCでも・・・ん・・・?
 
Azurevpn02
んんんん?!?!どゆこと~!!!
世の中の教本には西日本でサーバー建ててるやんっ!!!
 
なんでここまできて東日本っていうんだよ・・・orz...
 
その癖、SQLサーバーを建てようと思ってセットアップ進めて、サーバー選んでね…という所では西日本選べるんよ・・・。なんなん!?
 
仮想ネットワークゲートウェイ用サブネットが必要なのも全然つかめんし・・・。
 
まったく、先日はMSDNの手続きでイラっとさせられるし、ADFSは原因不明な悲鳴上げるし・・・Microsoft関係でずっとロクなことが起きてないっっ
 
あと3日で無料枠なくなっちゃうし・・・このままAzureはサヨナラかしら・・・。
とりあえず、AzureとVPNは別件でやらなきゃいけなかったんだけど、YAMAHAルーターじゃちょっち調子悪い事が分かった事だけは収穫なのかな・・・ポジに考えて・・・うん・・・そうだな・・・そういう事に・・・はい・・・。
 
はぁ。
ひと目でわかるAzure 基本から学ぶサーバー&ネットワーク構築 改訂新版

ひと目でわかるAzure 基本から学ぶサーバー&ネットワーク構築 改訂新版