DeepSecurityの件アップデートします。
先月DeepSecurityのManagerサーバを起動するとDBサーバのCPUが100%に張り付いてしまい、どうにもならなくなるという障害があったという話からサポセンも私も前回発生したのと同じこちらのデッドロック事象によるものと思っていました。
このため、デッドロック解除法の確認依頼をしていたのですが、アップデートすればデッドロック抑制できるという回答で、各サーバを再起動しても直らないので違和感を感じ、DBインスタンスのクリーンアップを行う事にしました。
まずはイベントDBのテーブル『dbo.event_historical』のインデックス作成(もしくは再構築。)と『dbo.event_data_historical』のインデックス再構築。
次に60日分を残してイベントDBのデータ削除
delete from [『イベントDB』].[dbo].[event_data_historical] where EventID in (select EventID from [『イベントDB』].[dbo].[event_historical] where Time < DATEADD(day,-60,getdate()));
delete from [『イベントDB』].[dbo].[event_historical] where Time < DATEADD(day,-60,getdate());
残念ながら、これではあまりDBサーバが軽くなりませんでした。
そこでvCenter DBの不要レコード削除を実施しました。(以下KB)
これによりvCenterDBのVPX_HIST_STATにある不要となったレコードが削除されましたが大量に生成してしまったVPX_HIST_STATのテーブル自体は消えないのでDB縮小にはならないですが、View Administratorのイベントなどの検索はかなり改善するようです。
残念ながらDeepSecurityのほうはDBの差分が大きくなりすぎたのかこれでは直らず、サポセンのほうからもDSMとvCenterとのリンクを一度切断してみるように言われています。
移動プロファイルとリンククローンの話
参考にしたMSのサイトのリンクを保存。。。したつもりでなくしてしまったみたいだったので、これから探しなおします。
移動プロファイルとフォルダリダイレクトで環境を作成する際に検討した際に困ったことについてですが
１．テスト後に本番リリース前の最終確認をしようとしたところ
テストではOUに設定して、本番でセキュリティグループにユーザプロファイルの
GPOを適用したところ適用されなかった。
→2016/6のMSパッチのせい
２．ポリシーの設定を誤ったせいでAdministratorでユーザプロファイルフォルダが
開けなくなりましたが、修正箇所は後で分かりました。
３．FSMOが物理的に故障し、クリーンナップして安定させたがDNS・DHCPのみ
利用する端末も含めて１台あたり600クライアントだったのが、1台減ったせいで
750台程度になった途端、移動プロファイルの読み込み失敗が多発した。
４．IMEが利かない。(appdata\local\microsoft\ime14\imejp\cacheのフォルダがないせい）
５．リンククローンにしたら、デプロイスクリプトでOffice2013のMAK認証が
コケるようになった。
※リンククローンをフルクローンのようにめったに更新せずに利用する場合の
適用方法は見つけました。
６．vCenterDBのログが妙にたまりやすくなった。
Horizon Clientをユーザフレンドリーにしたい
VDI環境で朝一番で発生する３大トラブル？といえば
１．共有プールユーザがIDとパスワード入力後にVDIに接続できない
①VDIが足りない
②VDIの待機数が足りない
③ADの調子が悪く、せっかく起動したVDIを他の人にとられてしまう(理由は不明)
２．Capsロックを押してしまってパスワードが通らない ※帰れ！と言いたくなる
３．シンクラのスタートアップに登録してあるHorizon ClientがDHCPサーバから
IP払い出し前に起動してしまってエラーになる。
特にノート型シンクライアントを利用しているとLANケーブルが抜けてるだの
無線LANの電波が取れないだの事務所の環境が悪い(悪いんですよ！)と
よく発生します。で、ITリテラシーの低い年配の方にノート型を提供すると
つながらないだけで連絡してきてしまって、シス管には非常に無駄な工数を
払わさせられてイライラが募ると思います。
そこで今回はHorizon Clientのアイコンのリンク先をEXEからVBSに変えて
起動前にConnection Serverのhttps(TCP443)への接続確認をおこない
つながらない間の６０秒間のうち前半３０秒は接続確認中というメッセージを
後半３０秒はLANケーブルか無線LANの電波の届くところへ移動するよう
促すメッセージを出して問い合わせする前に自己解決させるようなスクリプトを
組んでみました。
組んだあとにレジストリのRUNに設定しているbginfoも一緒に処理するように
すれば良かったと思いつつ、めんどくさくなってやめました。
vShiledEndPointのDBはvCenterDBと分けたほうがいい
先日、リンククローンのデプロイ失敗でまたSSOかと思いSSOのインストールされているvCenterサーバを再起動しましたが改善せず、SQLServerのメモリ枯渇に気がつきDBを再起動するため、View関係の全サーバの再起動を行ったあとリンククローンのLDAPおよびDBの不要情報確認(今回は削除はLDAPのみでした)を行ってプールのステータスをプロビジョニングを有効にすることでデプロイ自体は再開されました。
しかし、vShield製品のインスタンスも搭載しているvCenterDBサーバ再起動後もvCenterDBのCPU使用率100％となってしまったためvShield系の管理サーバを落としたところ症状の改善が見られる＝vShield製品のDB系不整合によると判断できる状態です。
リンククローンのデプロイができる状態になっても上記のvShield製品によるCPU100%状態は改善していないため、vShieldメーカに問い合わせをしています。
上記よりDB不整合の発生しやすい（確率が上がりやすい、というべきか)リンククローンを利用する場合にはvShieldのインスタンスはvCenterDBと別途持ったほうが良いかもしれません。
※View6.2.3
ThinAppでもWndows10に悩まされ。。。
この記事に関しては訂正させてください。
まず状況として、Adobe PhotoshopElement/Premireのパッケージでインストールする対象を選ぶ段階でpxhlpaによるThinAppのスキャンエラーがでてパッケージ生成に成功しても、64bit環境ですらコケて起動しない場合がありました。
この問題自体はHKLMのpxhlpaに関するレジストリ削除をするか、prescanをインストーラ実行直前まで行わない事で回避できるようだという事までわかりました。
訂正する本当の理由は別にあり、ThinApp5.2.2だからなのかまで判断できていませんが
64bitIOSでビルドしたパッケージを32bitで起動すると、パッケージ自体がOSのbit数判定をしているようで起動時に警告メッセージを出して終了してしまいます。
なお、パッケージ自体と判断した理由としてSandboxが生成していないことが理由です。
方法があるかどうかの追跡調査は別途継続する予定です。
VDI環境がWindows7 32bitのため、PhotoshopElement15もう64bitOSしかサポートしてないので使えません。いやユーザに必要って言われたら用意しないわけにいかないじゃないですか。
ということでThinApp先生に登場頂くためWindows7 64bitを新規で用意し、キャプチャ開始！したのですが、、、PhotoshopElement15がWindows10に対応しているせいなのかなにか知りませんが、ThinApp4.7.3でキャプチャしても英語メッセージでThinAppが対応していませんと表示されるわけでして。。
仕方なくThinApp5.2.0を使うべく複数あるライセンスのうち1つだけ5.2.0にライセンスのバージョンをアップしてシリアルをゲット。パッケージが無事起動するかどうかまでチェックしましたが一応OKなものの終了時にエラーが、、、。
少々気にはなりますが、まずは稼動するならOKということにしてパッケージ自体大きいため、分割しかできないようなため、シェイプアップできるかどうかこれから試します。
※ThinAppはこのように対応しているKernel同士であれば32bit＜＞64bit
ClientOS<>ServerOSとキャプチャしたものを持ち越せるので
制限事項はあるものの非常に便利です。
再度仮想環境のMTUについて検討中
FlexPodのVDI環境でNFSアクセス速度が出ないのでベンダーが音を上げたので途中であきらめてMTU1500／9000で環境を構築しましたが、その時点からMTUについてはオール9000でVDIのみMTU1500で構築すべきだろうと考えていました。
この理由として社内は管理できますが、インターネットアクセスでエラーになる可能性が否定できないと考えていたからです。
再度この件を詳細に検討(検証ではありません。テスト環境がない上、時間もありません。)すべき時が来ておりますのでデータセンタの通信機器のファームアップ作業の疎通確認テスト洗い出し作業と平行で進める予定です。
ちなみに考えるときが来た、というのはVMのサポセンにこの件を投げるとMTU1500とMTU9000のNWは分けてvスイッチ／ポートグループを作る事を推奨するという回答があること。これを行うと、VDI上でCristal DiskMarkを実行するとESX6.0の再起動のたびに約20－25%ぐらいの確率で非常に早い場合があった事も含めてvCenter上のパラメータと実際のESXのパラメータにおいてESXのNICのデバイスIDが入れ替わっているかのような挙動を示す事とネットワークのMTUの挙動を考慮してもサポセンの提示する回答を正しいと思っていません。また、今進めている仮想サーバの環境構築を下請けをVDIのFlexPodとは別の業者にしましたが、回答不可で戻ってきたので再度検討する事にした次第です。
とりあえず私の考えはFlexPod環境はネットワーク機器はオールMTU9000でゲストOSのうちDB等の受けが専門のサーバはMTU9000化し、送信が主で且つFlexPod外のシステムへの通信が多い物(VDIのインターネットアクセスなど）はMTU1500にするのが妥当だと考えており、この論拠とベンダへ理解させるための資料の準備をこれから進めます。
資料としてはRFCなども含めた物になると思いますが、別途掲載します。
Zabbixアプライアンスに奮闘中＃２
ちょっと基幹システム向けのFlexPod設置やら導入から7年越のシステムのリプレースでインフラ基盤の設計をまともにしないで持ち込む業者さんとの打ち合わせ後に現行の保守(これは一切関わってませんが)の課題だのあり、Agentインストができてませんでした。
とりあえず、ZabbixがDB認証が通らなくなるとWebコンソールの一番下に
『Zabbixサーバが動作していません(画面のリフレッシュを行ってステータスを再確認してください)』と出ます。サイトによってはDB接続パスワードをコピーしてmySQLのコンフィグの.my.cnfに上書きと書かれているサイトもありますが、Web画面で上記メッセージが出なければ問題ありません。
後、前回resolv.confにseach hogeghoge.localと追記してローカルドメインにhost名でアクセスできるようにしましたが、再起動するとnetwork managerでresolv.confが初期化されてしまい、LDAPアクセスができなくなってWEBコンソールにログインできなくなりました。DNSは/etc/network/interfacesにdns-nameserverとして追記すればOKだったのですが、seachの代わりがdns-seachのようです。数年Linux構築していなかったのがバレバレですな、これは。
アプライアンスですが当然時刻が全く合ってませんので、合わせてください。またNTPクライアントやnslookupのコマンドもないのでインストする必要がありました。
sudo apt-get install ntp
sudo apt-get install dnsutils
#--------------------------------
前回の修正をば。resolv.confがnetwork managerに初期化されるため
sudo vi /etc/network/interfacesでeth0の設定を以下のように変更
auto eth0
iface eth0 inet static
address 192.168.1.121
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameserver 192.168.1.100 192.168.1.111
dns-domain hogehoge.local
信頼関係を結んでいるドメインやらがある場合、そちらに対してホスト名でアクセスするのであれば、dns-seachで設定するようです。
#--------------------------------
アプライアンスだからなのかnslookupがインストされていないため sudo apt-get install dnsutilsでインストールします。
次にテスト端末(Windows 64bit)にZabbixAgentをインストするためダウンロードして、conf/zabbix_agentd.win.confをbin/win64にコピーし修正します。
LogFile=C:\Program Files\zabbix_agents_win64\zabbix_agentd.log
bin/win64のディレクトリをProgram files配下に配置するつもりのためzabbix_agents_win64に変更し以下を変更。
LogFile=C:\Program Files\zabbix_agents_win64\zabbix_agentd.log
Server=Z@BBIX ※Zabbixサーバ
ServerActive=Z@BBIX:10051
#Hostname=127.0.0.1
※コメントアウトするとWindowsのホスト名を動的に取得します。
※HostnameItemとHostMetadataを変更しているサイトもありますが
いったん変更なしでいきます。
zabbix_agentd.exe -i -c zabbix_agentd.confでインストール。
zabbix_agentd.exe -s -c zabbix_agentd.confでサービス起動できますが、サービスにも登録されていました。
この時点でログファイルのzabbix_agentd.logを見ると末尾に
no active checks on server [ZA@BBIX:10051]: host [SERVER001] not found
と出る場合があります。というかWebコンソールで何もしていないと出ます。
Webコンソールにログインし、【設定】>【ホスト】＞【ホストの作成】の画面右上にある【ホストの作成】でエラーで表示されたホスト名と同じく大文字小文字をそろえて登録する事で検知できるようになるようでzabbix_agentd.logにエラーが出なくなります。
