シングルサインオンの製品

ICカード指紋認証でworkgroupのシンクライアントからログインするシステムってそんな難しい物だったんでしょうかね?
今日、とあるSIerさんにアポとって仮想環境で使える認証と言うことでお話聞いたのですが、
接続元もドメイン参加が前提という残念な結果でした。BYOD非対応という意味ですので折角の複数認証の価値がほぼないと判断しました。
敢えて聞きませんでしたがゼロクラも当然非対応でしょう。これで仮想環境対応していると言われると思いませんでした。

元々私が想定していたシンクライアントドメイン参加は、シンクライアントドメインのユーザがVDIドメインには接続できない
片方向信頼関係のドメインとして構築し、View ClientでID/PASS、ドメインを選択する事を想定していました。
こうする事で、管理者PCのDNSサフィックスにシンクラのドメインを追加すればユーザからは見えずセキュリティ面でも無駄なアカウントがなく
進入されないが、Viewクライアントで重要なシステムタイムのずれが発生してもADによる時刻同期強制によりハードウェアクロックがずれても
修正される(はず)といった運用面での利便性が得られるという事を考えていました。

そういった観点でこのSIerさんの製品では特定を防ぐため詳細は書きませんがADに手を加えて対応するという事だったので
シンクライアントから認証できる必要がある=同ドメインか双方向信頼設定が必要という事で
打ち合わせ開始10分以内に状況が厳しいと判断した次第です。

変わった商品紹介

データセンタや遠隔地に設置しているネットワーク機器やONUを再起動したいけど、どうにもならない時がありませんか?ありますよね?そんな一人社内SEの皆さんに商品のご紹介です。(ジャジャーン

www.amazon.co.jp

httpでこの機器に接続してコンセントの給電をとめてくれたり、Pingポーリングに失敗したら再起動といった管理ができる優れものです。Amazonでも66000円するので高いですが、保険として導入を検討する価値があると思います。

ちなみに残念な点はラックマウントキットはありますが、19インチラックにはうまく収まりませんでしたので棚板買ってくださいね。

GPU利用のユーザさんの障害に関して報告いただきました。

以前GPU付のVDI環境のユーザさんで熱による障害ではないか?という記事をあげましたが、本当にそうだったと報告いただきました。

解決策ですが、ラックのコンソールと反対側(背面側)の扉にファンを取り付けました。設置位置としては熱が抜けやすくなるようにブレードシャーシの1つ上から上のユニットに3連ファンを設置したところ5度程度は低下したとのことでした。
このユーザさんの環境では、一時障害として熱でGPUが故障し交換。そして2次障害としてGPUを搭載しているとVMXファイルにGPUのシリアルが記載されるらしく、故障でゲストOSが落ちるとVMX上のシリアルが消えて制御が利かなくなる…様な状態だったようです。

現場に立ち会ったメーカSEさんも目を白黒させていたそうなので、メーカさんにもこういった知識を持ってもらえると利用者としては安心して導入に踏み切れるようになるのではないでしょうか?

Connection Serverのイベントログ

放置するとイベントウィンドウでユーザIDを検索してもタイムアウトしてしまいログが出なくなります。この対処としてDBのクリーンナップとインデックス作成が必要になりますが、それでも放置するとインデックスを貼ろうとしても貼れなくなります。VMのサポセンに問い合わせると『マニュアルで定期的にクリーンナップしてください』と言われます。VMware Horizon View 6.x でイベントデータベースのパフォーマンスが極端に低下する (2099872)

VMware Horizon View 6.x でイベントデータベースのパフォーマンスが極端に低下する (2099872)
https://kb.vmware.com/kb/2099872
念のため消し方についてサポセンに聞くとコミュニティのスレを案内された事があります。

communities.vmware.com

 

展開中のリンククローン展開開始が遅れた理由

リンククローンは現在新人君に展開作業を委ねました。

元々、フルクローンのVDIを流動プールで利用するように設定しローカルプロファイルでの利用な上、130台もあったのでプロファイルは基本的に7日で自動削除されるようにローカルポリシーで設定していました。

当然こんな利用方法ではユーザからは『毎日のプリンタの設定が面倒』だの『お気に入りが消えるのが面倒』だのいわれるわけですが、これについては私の入社前からずっとこの設計でした。
そもそもこの設計だったのは、既存社員(退社した方も含めて)の技術力と1案件単位でのコスト制限の影響があった事、またVDI=システムトラブルでデータがVDIごと飛ぶという印象が会社的にあり、安定稼動する環境を作る事が最優先されてきた事に起因しています。この問題をView5導入時にドメインコントローラやネットワーク等社内の全てを平行で見直しを行い、3年間フルクローンで正常稼動させる事ができた事から踏み切る事ができたという背景があります。
とはいえ、本来であれば年度末には展開開始できる状態だったはずなのに遅れた原因は展開開始直前にFSMOを持ったドメコンが故障したことに起因します。このドメコン、私が入社する前から存在し、かつ設計ミスと内政的問題でView導入からしばらくの間まではメモリ2GB(笑)で稼動しており、それを一度メモリを追加&OS再インストして利用していました。このマシンが、ハードのアラートは出ていないものイベントログ等で正常に処理できていない事を確認し、FSMOをTransferコマンド、Seizeコマンドで転送しようとしても受け付けない状況で再起動してやっと受け付けるようになり、その後シャットダウンしました。しばらく様子見していたのですが、よくよく調べるとLDAPDNSと信頼関係のデータが重複レプリケートされており、それらを手動削除後に展開開始する事になったという状況です。

久しぶりなので近況から

ずいぶん間が開いてしまったので見ている方ももう少ないでしょうが、時間的余裕はかけらもありませんが、やっと精神的な余裕が出てきました。

自称一人社内インフラ課課長(笑)の状態だったのが、まず4月になって変わったこととして一人仮想エンジニアが入りましたので彼を調教教育しています。彼の課題としては運用をやったことがないため、先日あえて思うようにやってもらったんですがWindows関連のアップデートでVDIを再起動せずにインストールし翌日以降でエラーが多発しました。一応、実施する前に『とりあえず再起動推奨』とは言ったんですが、そのまま実行したので、運用は経験がモノをいうということを理解頂けたでしょう。

また、社内インフラ課員としてはネットワークは必須ですが、詳細設計はベンダに投げられる体制を作っていますので(私は納期短縮のため詳細設計まで軽くまとめてから投げてますが)、まずは概要設計がある程度できるようになってもらいたいと思っています。

とりあえず後で買って読ませてテストまでするつもりですが、以下の本を私が買って仕事中にでも読ませようと思っています。

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

 

Amazon CAPTCHA


先ほど立ち読みでサラサラっと見た程度ですが、過去の経験と照らし合わせても正しく理解できる内容が書いてあると感じられました。正直、マスタリングTCP/IPとかそういうのも重要ですが、社内SEとして重要なのは概要設計ができる事とコンフィグからどのような設計になっているか理解できることで設定できることであって、パケットの中身でどこがおかしいだのということが必要になるケースは殆どありません。
個人的には3WAYハンドシェイク等は知っている必要はありますが、パケットレベルでの解析が必要な事態になったのは汎用機とIAサーバのHULFT伝送でのソフトバージョン違いで双方向NAT環境で通信ができなかった時ぐらいでしょうか?
そういった観点からまずはネットワーク運用をやったことがない彼の教科書として最適だろうと考えています。

そんな事いって、自分はそういうの勉強はいらんのか?という話になると思いますが一応考えてはいます。同じ著者の本ですが

www.amazon.co.jp

私も今対応中の仮想サーバ基盤でロードバランサのワンアーム接続を行っておりますがそういった内容から仮想環境のネットワークまで触れられておりこちらも立ち読みでさらっと見た程度ですが、かなり良い内容でした。自身の理解を見直す事と新人のNEとしての第二ステップにちょうど良いだろうと考えています。

FlexPodが厳しいです。

昨年9月から(といっても納品の関係で構築開始は10月だったのですが)構築を開始したゲストOS領域としてNFSを利用したFlexPodですが、状況が芳しくありません。
なお、現職の環境はSIerのN社と下請けとしてU社系が仮想環境を構築してきたのですが少々前から参入したC社がノウハウあります!やります!ということでU社に代わり下請けに入り構築が始まりました。

10月末に基礎構築が終わりVDIを展開した時点で、デプロイ時のVMDKファイルのコピーに既存のSAN環境と比較し1.5倍の掛かっており、当初はNFSアクセスだからこんなものなのだろうか?と思っていました。しかし、実際にログインして利用してみると異常に操作感が悪く、とりあえず使い慣れたCristalDiskMarkを利用し、I/O測定をするとVDIとしての利用感に一番影響の大きいランダムリードが異常に悪い結果が出ました。

スクリーンショット類はまだ整理中ですが、既存SAN環境がランダムリード200程度出る(IOPS18k程度)のに対し、当初30前後か下手すると一桁が出るときもありました。明らかに異常だと判断しましたが、生憎DWH2セットのハードリプレースがあり、これに伴うフルクローンVDI1000台にインストールされたODBCソフトウェアセット3本を入れ替える作業込みで一人で行う必要があったため、ひとまず担当SEに任せざるを得ませんでしたので、状況からESX再インストールを検討するように支持をしました。この時点で担当SEのCisco/VMwareによるリリースバージョン認可が下りておらずサポートが受けられないという板ばさみがあり、構築が進みませんでした。※それ以外にもISOイメージに最新のドライバが組み込まれていなかった等、あまり考えられない問題ばかりが発生しました。

次の課題は、C社が弊社からのRFPや今後の展望を記載した資料を渡していたにもかかわらず要求事項(従来のSANと異なりNFSになるので差分を吸収できるSEの協力が必要)を理解していない事とそれが出来るSEがいないことが判明しで、私の手が空く1月まで放置になってしまいました。

詳細な情報についてはこれからまとめますが、FlexPodのパフォーマンスチューニングでここまで行った内容と抱えているトラブルに関してまとめます。

まず、BIOS関係についてですが、HPやLenovoDellのサーバであればBIOS設定でPower Managementの項目でハイパフォーマンスにすれば完了なのですが、UCSの場合は自作PC並みにCPUやメモリの項目が存在します。分かりやすいところでいけばHyper-Threadなどですね。これらの項目をひとつずつ精査する必要があります。また、NFSアクセスではVMware社のセールスSEも仰っていましたが、ストレージメーカの推奨値とVMwarenの推奨値があり。基本はストレージメーカの推奨値を優先するとの事。ここでいう値は、vSphere Clientで設定可能な各ESXの詳細パラメータになります。これとMTU1500から9000への変更がメインとなります。

上記の対応により、ランダムリードが20-30程度から140-150程度まで上げることは出来たものの観測した中での最大値の190を常時キープできるところまでは調整できていないため、調査を継続している状況です。このIOPSが伸びない状況ですが、測定中にCPU使用率が50%程度と低い場合に190近い値が測定され、100%近い場合は非常に低い値で出るという症状とESXの再起動を実施するたびに状況が変わる(ただしいい結果が出る確率は20%程度)ということからESXに何がしかの問題があると判断し調査を進めています。

実際、UCSのサーバではsyslog.logで以下のログ等の異常なものがかなりの頻度で生成していることも確認されていますので、VMのサポセンに問い合わせはしているものの最終的には再インストを視野に入れざるを得なかろうと個人的には判断しています。

2017-01-16T23:03:32Z sfcb-CIMXML-Processor[127805]: pam_succeed_if(sfcb:auth): error retrieving information about user 52ce06d9-5323-b432-cd03-9a4e550cee43 •ESX/ESXi 4.1 および ESXi 5.0 ドメイン メンバーとユーザー認証による ESX Admins AD グループの使用 (2074017) https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025569