2018-06-06

 日本ではIT部門が技術サポートを社外の協力会社へ委託する例が大半である。ここでHWやSWのサポート問い合わせは委託元からのみ、委託先からは認めない!として、業務が回るのであろうか?
 
 今までは「代理保守ユーザ」として委託先を登録、問い合わせ時は委託元もcc:で返信先へ入れ、委託先が関係無い質問を牽制する様になっていた。
 
 この改悪後は委託先のSIerが委託元の担当者(2名しか登録出来ない)へ問い合わせ依頼、委託元がベンダへ問い合わせ対応、という事になる。

 ただでもこのベンダの製品は不具合やマニュアルの不備が多いので問い合わせが多いので、勘弁頂きたいところである。
 今後は他社製品を提案するか。


「保守ユーザーと別会社の方が代理保守ユーザーとしてお問合せいただいている場合は、 5月27日以降、一時的な問合せにつきましても受付をお断りさせていただきます」

https://www.manageengine.jp/news/note_20180514.html

保守ユーザー登録者数の変更について

2018年5月14日

ManageEngine製品の保守契約においては、これまで保守ユーザーは1名のみ登録でき、 登録したユーザー様からお問合せを受け付ける取り決めとなっておりましたが、 このたび2018年4月より登録済みの保守ユーザーと同一会社名であれば、2名まで保守ユーザーを登録できるようになりました。
※登録いただく際は、個人名でお願いしており、団体名/部署名でのご登録はご遠慮いただいております。

保守ユーザーの追加/変更は、ユーザーポータルより実施いただけます。

ユーザーポータルURL: https://ssl.zoho.co.jp/UserPortal
ユーザーポータルマニュアル:https://jpmeuser.wiki.zoho.com/userportal.html
FAQ:https://jpmeuser.wiki.zoho.com/faq.html

これまで代理保守ユーザーとしてご連絡いただいておりましたお客様からも一時的にお問い合わせを受け付けておりましたが、今回の変更に伴い、5月27日以降は保守ユーザーとして登録されている方からのみお問い合わせを 受け付けることとなります。
現在、保守ユーザーと別会社の方が代理保守ユーザーとしてお問合せいただいている場合は、 5月27日以降、一時的な問合せにつきましても受付をお断りさせていただきますので、あらかじめご了承いただければと思います。

また、ご登録いただいた保守ユーザー2名の方から同時にお問合せいただいた際は、これまでどおり、優先度に応じて順次対応いたします。

 マルハニチロの株主優待だが、さりげなく改悪されていた。
 2年前の株主優待はカニ缶が4個、魚缶が2個であった。
 今年はカニ缶が2個に削減。魚缶が4個に。

 違和感があって過去株主優待を他の人のblogで確認したのだが、こういうのは残念、

2018-05-21

 VMware vSphereによる仮想化基盤を構築する案件が色々ある。ここで業務チームが以来してくる計算機資源の設定が何時も問題になっている。

 筆者の所属する企業の案件は東証1部のかなりの部分を占める中堅規模の企業が多く、TOPIX coreになるような大規模な案件は少ない。案件は生産、販売、会計の業務が多い。

 結論から書けばサーバのCPUに投資するより、ストレージに投資する方がコストパフォーマンスが良い。また仮想化基盤ではVMに割当するvCPUは最小限に抑えるべきである。

 業務チームの方々から「DBは8vCPUで!」と元気よく依頼される事が多々ある。
 本当にこれだけ必要なのか?というと大概は不要である。大概のDBサーバを観察するとCPU使用率が100%になる事は滅多にない。しかしながら、経験豊富な業務チーム程要求CPUが多くなるのだ。
 これは古い案件では「性能が心配なので、物理DBサーバでは4コアCPUを2ソケット」と言った構成が多かったのでは推測している。この手のシステムを一度経験してしまうと、以前よりCPU数を減らすのは抵抗感があるのだろう。また、業務システムを構築後、基盤負荷を定期的に確認するという文化が根付いていないので、適切なサイジングだったか?というフィードバックがなされていないのもあると思われる。

  さて、この過剰な要求をそのまま現代の仮想化基盤で設定してしまうとどうなるのか?
 現代の仮想化基盤ではCPUはある程度オーバーコミット設定するのが定石である。オーバーコミット状態で多数のvCPUをVMへ割り当てしてしまうと、VMが動作開始するには設定したvCPUが全て利用可能になるまでVMは起動を待つことになる。この起動待ちはVMwareではReadyとして表示される。 このReadyが増加していることは折角の仮想化ホストのCPUが有効に利用されていないという事である。また、vCPUを過剰にするとVMが起動するまでの待ち時間が増え、結果的に遅くなってしまう。

 アプリケーションがマルチスレッドに対応しておらずCPUを有効に使えないのであればvCPUを増やしても過剰なvCPU設定は性能劣化の原因となってしまう。

 加えて前述のような中堅向けのシステムではOracleもStandard Editionが殆どである。Enterprise Editionであれば、パラレルクエリでCPUが多い効果が得られる(LINK先PDF)。Standard Editionではアプリケーションで相当意識しないと、CPUを増やしても効果は少ない。
 また、前出のOracle社の資料にある通り、DB性能ボトルネックはCPUが全体の9%であり、大半はI/OとSQLに問題があるとなっている。IBM社の調査ではI/Oの待ちでCPUが効率的に利用できないとある。
 VMware Essential Plusで構築可能な仮想化ホスト3台の構成でもSSDによるDBのボトルネック解消とCPU削減、この結果のコストの削減は十分に可能である。

2018-05-16

 Windows Serverでsyslog受信の無料ツールを探してみた。

 GPLでvisual syslogserverというのがあるので試してみた。
 syslog受信の基本機能は当然あるが、ファイルのローテーションがあるのが有難い。毎日ファイルとして切り出し、日付をファイル名に付加して保存、さらに世代数の設定もあるので有償製品と同等の運用が可能である。

 残念なのはサービスとして起動が出来ないこと。
 freeでNSSMを用いてサービス起動は可能なのだが、一旦コンソールを起動後、logoutするとsyslogが記録されなくなってしまう。サービスとしては起動し続けているだが。
  仕方がないので、logoutではなくRDPを切断、という運用で対応している。

 やっぱりKiwi syslog server辺りの有償製品が必要か...。
 NAS4Freeでminidlnaを使って.tsファイルなどをXBianで動画再生できる様にしている。

 ところが、ファイルを更新してもXBianで新しいファイルが認識されないという問題が。

 ここでrescanを押すとNAS4Freeが再起動してしまう。
 仕方がないので、/zfs_pool/var/files.dbを削除後、再起動したところrescan、file.dbが再構築されて更新したファイルも認識された。

 ファイルが多すぎるのが原因なのかな?

2018-05-15

 HP Microserver firmware 1.4でjavaをupdate後、remote KVMからRACへ接続できなくなった。

 原因はjavaのupdateで古い暗号suiteを明示的に禁止しているための様である。

 jre1.8.0_171/lib/security/java.security

 の

 jdk.tls.disabledAlogorithmsの行から3DES_EDE_CBCを削除すると接続できる様になる。本来はRAC側で対応するべき事項だが、有償保守に加入していないと更新版firmware が入手出来ない&これに対するupdateが提供されているのか?というのが困った所。




# Example:
#   jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, DES40_CBC, RC4_40

 

2018-05-14

 忘備録として。
 社内のapplication serverを社外から安全に使用したいという事で、Windows Sever 2012R2のIIS8.5を用いたreverse proxyを構築した。
 単体テストは問題なく通過したのだが、後日「特定の画面がstatus 400で開かない」という連絡が。

 この場合、IISのログには何も出力されない。
 別途以下に出力される。

C:\Windows\System32\LogFiles\HTTPERR\httperr1.log
 
 確かにここを見ると、status code 400で実際にブラウザから送信された内容も含まれている。

 で、application serverが出力するhtmlはかなり長いwicketを含んでいる。これが長すぎて上手く行かないと判明した。


 標準ではパスセグメント長は260文字の様で、これをレジストリ変更で伸ばすと正常に動作した。

自己紹介

自分の写真
東京都, Japan
憂鬱な凍死家です。こちらではmixiとは異なり固めの話題中心です。

Total Page View

Categories

Powered by Blogger.

Popular Posts

Blog Archive