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文字の様で、これをレジストリ変更で伸ばすと正常に動作した。

2018-05-11

 Oracle 12c 12.2.0.1で標準インストールすると、temp fileはtemp01.dbfが1個作成される。これは自動拡張がonになっており、初期は小容量だが必要に応じて拡張される。一度拡張されると、ファイルシステム上の容量は減少せず、内部の使用容量が減る仕組の様である。

 ところで、temp fileは1ファイル辺り32GB(正確に言うと32G-1)の上限がある。たとえ自動拡張をon設定してもtempが何らかの理由で32GBまで拡張されると、これ以上自動拡張出来ないため、実際にtempとして32GB使用する事が無くてもORA-01652のエラーが発生してしまう。

 この場合は、tempファイルを例えばtemp02.dbfを作成し追加すれば良い。その結果、拡張の余地が生まれるため前述のエラーは発生しなくなる。

 また、1セッション辺り32GB以上tempを必要とする場合は、temp01.dbfが32GBを超えて大きくなる。それと同時にtemp02.dbfが使用率が低いまま(内部は未使用のまま)自動拡張されていく。この時、temp01.dbfとtemp02.dbfとの容量合計値が必要なtempファイルの容量となっている。
 tempが解放されると、temp01.dbfは上限である32GBになり、temp02.dbfは拡張されたままとなる。

2018-05-10


 VMware ESXiやvCSAはログをsyslogとして出力する機能がある。
 ESXiのlog必要性は低いのだが、bug発生時の解析用途で取得しておくに越したことはない。ところで、ESXiは標準状態だとverboseなlogが大量に出力されるためsyslogが大量に発生してしまった。1日GB単位で増加するので流石に修正が必要である。

 先ずはVMwareのkb2000088を参照してログレベルを変更した。これでhostdとvpxaのログは変更できるのだが、rhttpporxyのログが非常に大量に出力され続けている。
 VMwareの有償サポートでは「変更方法は提供しておりません」との回答であったが、非公式情報ではあるものの、rhhtpproxyとfdmの変更も可能である。

 筆者の環境ではrhttpproxyのログが大量に発生しているため、これを修正した。

/etc/vmware/rhttpproxy/config.xml

 の

 <level>warning</level>

 の様に出力するレベルを変更すれば良い。
 Lenovo System x3550M5へVMware ESXi6.5U1 Lenovo customizedをインストール。2018/3時点のVMware提供updateを一式適用した環境があった。
 ESXiのタスクを見ると、1sec毎にdcuiのlogin,logoffが記録されている。

 Lenovoのサポートフォーラムでも類似の事象は報告されている(1)(2)のだが、Lenovoが組み込んだcronによるタスクは本来1分1回起動される筈。前述の様に1秒に1回以上の頻度では一瞬でタスク履歴とsyslogが溢れるし、運用上も支障がある。

 結論から書けば、LenovoのVMware用レポジトリをupdate managerへ追加し、2018/4頃追加されているLenovoのアップデートや2018/5頃追加されているVMware提供のsystem x用アップデートを適用したところ、1分に1回の頻度になった。


 LenovoのforumからlinkされていたIBMのsupportでは、Ethernet over USBを無効にしろ、とあったが効果はなかった。

Solution #1
1) attempt to disable the vusb0 interface first to confirm this is the source of the issue:
For a blade server:
1. Launch the IBM BladeCenter Advanced Management Module.
2. Go to Blade Tasks > Configuration> Information and Policy.
3. Select Advanced Blade Policy Settings.
4. Select Ethernet over USB.
5. Select the blade server where you want to disable the ethernet interface, then click Disable.
2) update the IMM firmware to current version

a) You may also be able to update the IBM CIM Providers via IBM Fix Central


 切り分けのため、crontabを編集してrefresh.shを起動しているcronの設定をコメントアウトすると、上記のlogon,logoffは止まった。但し、crontabを編集しても再起動すると無効になってしまうので、これ自体は恒久的な対応には出来なかった。
 バックアップを取得したところでraspbianをjessieからstretchへ更新してみる。基本はクリーンインストールとのことだが、sambaを再構築するのも非現実的なのでupgradeに挑戦。

 先人の記事を参考にしてみたが、手順で問題となる箇所は無し。

 raspberry pi 2で更新したのだが、途中で入力する箇所もあるので所要時間は一晩必要である。

 レポジトリ情報の更新は以下を実行。

sudo sed -i 's/jessie/stretch/g' /etc/apt/sources.list
sudo sed -i 's/jessie/stretch/g' /etc/apt/sources.list.d/raspi.list

 パッケージ情報の更新は以下を実行。

sudo apt-get update

 アップグレードは以下を実行。
 この際、「設定ファイルをそのまま残すか、新しい物で上書きするか」と数回質問が発生した。標準は「設定ファイルをそのまま残す」となっているので、随時enterを入力。
 また、「サービスを再起動しても良いか」は標準が「no」なので「yes」を選択。

 ログを眺めていると、パッケージの依存性で警告が数回表示されていたが、特段問題は無い様だ。


sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade
sudo reboot

---
設定ファイル '/etc/ntp.conf'
 ==> これはインストールしてから (あなたかスクリプトによって) 変更されています。
 ==> パッケージ配布元が更新版を提供しています。
   どうしますか? 以下の選択肢があります:
    Y か I  : パッケージメンテナのバージョンをインストールする
    N か O  : 現在インストールされている自分のバージョンを残す
      D     : 両バージョンの差異を表示する
      Z     : 状況を調査するためにシェルを開始する
 デフォルトでは現在使っている自分のバージョンを残します。
*** ntp.conf (Y/I/N/O/D/Z) [デフォルト=N] ? n
---


 最後に不要なパッケージを削除。以下を実行。

sudo apt-get --purge -y autoremove 

2018-05-05

 無事回復したraspberry piであるが、再度おかしくなると怖いのでバックアップを取得する。
 今まではSDカードを抜いてmacでSDカードの中身を.img形式に取得してきたのだが、時間が掛かることと、バックアップを書き戻す先のSDカードは容量がオリジナルと完全に等しいか大きいものとする必要があった。各所に書かれている通り16GBのSDカードと称していても微妙に容量が異なるのである。

 調べたところ、rpi-cloneが便利そうである。これはCLIで動作するのでjessie liteに適合する。

 git hubで公開されているので、先ずはgitを導入する。


pi@raspberrypi1:~ $ sudo apt-get install git
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
  git-man libcurl3-gnutls liberror-perl
(中略)
git-man (1:2.1.4-2.1+deb8u5) を設定しています ...
git (1:2.1.4-2.1+deb8u5) を設定しています ...
libc-bin (2.19-18+deb8u10) のトリガを処理しています ...

 導入後、rpi-cloneを導入する。

pi@raspberrypi1:~ $ sudo git clone https://github.com/billw2/rpi-clone.git
Cloning into 'rpi-clone'...
remote: Counting objects: 158, done.
remote: Total 158 (delta 0), reused 0 (delta 0), pack-reused 158
Receiving objects: 100% (158/158), 75.04 KiB | 0 bytes/s, done.
Resolving deltas: 100% (59/59), done.
Checking connectivity... done.

 導入後、一式を/usr/local/sbin以下にcopyする。

pi@raspberrypi1:~ $ ls
rpi-clone
pi@raspberrypi1:~/rpi-clone $ sudo cp rpi-clone /usr/local/sbin
pi@raspberrypi1:~/rpi-clone $ type rpi-clone
rpi-clone は /usr/local/sbin/rpi-clone です

 SDカードリーダにSDカードを挿入後、raspberry piへUSB接続。認識されているかを確認。認識されていない場合は再接続してみる。

pi@raspberrypi1:~/rpi-clone $ lsusb
Bus 001 Device 004: ID 0411:0259 BUFFALO INC. (formerly MelCo., Inc.)
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 マッピングを確認する。/dev/sdcとして認識された。

pi@raspberrypi1:~/rpi-clone $ sudo fdisk -l

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
(中略)
Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1        8192   137215   129024   63M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      137216 31116287 30979072 14.8G 83 Linux

Disk /dev/sdc: 14.5 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdc1        8192 30375935 30367744 14.5G  c W95 FAT32 (LBA)

 認識された/dev/sdcへ書き込みをする。
 途中でext4のパーティションの名前をどうするか?と質問されるが、元々付与されていないので、そのままenterで続行して良い。
 完了したら、shutdown後、SDカードを入れ替えて起動してみる。


root@raspberrypi1:/home/pi/rpi-clone#  rpi-clone sdc --force-initialize

Booted disk: mmcblk0 15.9GB                Destination disk: sdc 15.6GB
---------------------------------------------------------------------------
Part      Size    FS     Label           Part   Size    FS  Label
1 /boot   66.0MB  fat16  --              1      15.5GB  --  --
2 root    15.9GB  ext4   --
---------------------------------------------------------------------------
== Initialize: IMAGE mmcblk0 partition table to sdc - forced by option ==
1 /boot               (23.6MB used)  : IMAGE     to sdc1  FSCK
2 root                (6.5GB used)   : RESIZE(15.5GB) MKFS SYNC to sdc2
---------------------------------------------------------------------------
Run setup script       : no
Verbose mode           : no
-----------------------:
** WARNING **          : All destination disk sdc data will be overwritten!
                       :   The partition structure will be imaged from mmcblk0.
-----------------------:

Initialize and clone to the destination disk sdc?  (yes/no): y
Optional destination  ext type file system label (16 chars max):

Initializing
  Imaging past the start of /boot partition 2.
  => dd if=/dev/mmcblk0 of=/dev/sdc bs=1M count=71 ...
  Resizing last partition to end of disk ...
    Resize success.
  Changing destination Disk ID ...
  Delaying so partprobe can update /dev entries ...
  => fsck -p /dev/sdc1 ...
  => mkfs -t ext4  /dev/sdc2 ...

Syncing file systems (can take a long time)
Syncing mounted partitions:
  Mounting /dev/sdc2 on /mnt/clone
  => rsync // /mnt/clone with-root-excludes ...
  Mounting /dev/sdc1 on /mnt/clone/boot
  => rsync /boot/ /mnt/clone/boot  ...

===============================
Done with clone to /dev/sdc
   Start - 08:34:08    End - 09:15:01    Elapsed Time - 40:53

Cloned partitions are mounted on /mnt/clone for inspection or customizing.

Hit Enter when ready to unmount the /dev/sdc partitions ...
  unmounting /mnt/clone/boot
  unmounting /mnt/clone
===============================


2018-05-04

 raspberry piのjessieでapt-getが急に動作しなくなった。

root@raspberrypi2:/home/pi# apt-get
apt-get: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libapt-private.so.0.0: undefined symbol: _ZN3APT6String8EndswithERKSsS2_

 さっぱり判らないので色々検索してみたが、apt-getをdpkgで再導入すれば良さそうである。
 先ずはaptのパッケージを再入手。

root@raspberrypi2:/home/pi# wget https://archive.raspbian.org/raspbian/pool/main/a/apt/apt_1.0.9.8.4_armhf.deb

 その後、再導入してみたが、依存関係でエラーになってしまった。

root@raspberrypi2:/home/pi# dpkg -i apt_1.0.9.8.4_armhf.deb
(データベースを読み込んでいます ... 現在 34855 個のファイルとディレクトリがインストールされています。)
apt_1.0.9.8.4_armhf.deb を展開する準備をしています ...
apt (1.0.9.8.4) で (1.0.9.8.4 に) 上書き展開しています ...
dpkg: 依存関係の問題により apt の設定ができません:
 apt は以下に依存 (depends) します: libapt-pkg4.12 (>= 1.0.9.8.4) ...しかし:
  システム上の libapt-pkg4.12:armhf のバージョンは 0.9.7.9+rpi1+deb7u7 です。

dpkg: パッケージ apt の処理中にエラーが発生しました (--install):
 依存関係の問題 - 設定を見送ります
man-db (2.7.5-1~bpo8+1) のトリガを処理しています ...
処理中にエラーが発生しました:
 apt


 どうもlibapt-pkgが宜しく無い様子。これも再取得して再導入。
 その後、再度aptを導入したところ、正常に動作した。

root@raspberrypi2:/home/pi# wget http://ftp.us.debian.org/debian/pool/main/a/apt/libapt-pkg4.12_1.0.9.8.4_armhf.deb
--2018-05-04 22:23:22--  http://ftp.us.debian.org/debian/pool/main/a/apt/libapt-pkg4.12_1.0.9.8.4_armhf.deb
ftp.us.debian.org (ftp.us.debian.org) をDNSに問いあわせています... 208.80.154.15, 128.30.2.26, 128.61.240.89
ftp.us.debian.org (ftp.us.debian.org)|208.80.154.15|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK

root@raspberrypi2:/home/pi# dpkg -i libapt-pkg4.12_1.0.9.8.4_armhf.deb
(データベースを読み込んでいます ... 現在 34855 個のファイルとディレクトリがインストールされています。)
libapt-pkg4.12_1.0.9.8.4_armhf.deb を展開する準備をしています ...
libapt-pkg4.12:armhf (1.0.9.8.4) で (0.9.7.9+rpi1+deb7u7 に) 上書き展開しています ...
libapt-pkg4.12:armhf (1.0.9.8.4) を設定しています ...
libc-bin (2.19-18+deb8u10) のトリガを処理しています ...
root@raspberrypi2:/home/pi# dpkg -i apt_1.0.9.8.4_armhf.deb
(データベースを読み込んでいます ... 現在 34856 個のファイルとディレクトリがインストールされています。)
apt_1.0.9.8.4_armhf.deb を展開する準備をしています ...
apt (1.0.9.8.4) で (1.0.9.8.4 に) 上書き展開しています ...
apt (1.0.9.8.4) を設定しています ...
man-db (2.7.5-1~bpo8+1) のトリガを処理しています ...
libc-bin (2.19-18+deb8u10) のトリガを処理しています ...


 取り敢えずこれで稼働するようになったのだが、対処として正しいかは不明。

自己紹介

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

Total Page View

Categories

Powered by Blogger.

Popular Posts

Blog Archive