旧サーバDL320G6 CentOS5.5を新サーバDL380G7 ESXi 6.0U1に統合した。
vConverterが使えれば楽なんだけど、RAID構成から分析エラーで動かなかったので、手動でできる限りダウンタイムを減らしつつP2Vを実施。
※お名前VPSとかに持ってくにも概ねこの手順でOK
(926)
旧サーバDL320G6 CentOS5.5を新サーバDL380G7 ESXi 6.0U1に統合した。
vConverterが使えれば楽なんだけど、RAID構成から分析エラーで動かなかったので、手動でできる限りダウンタイムを減らしつつP2Vを実施。
※お名前VPSとかに持ってくにも概ねこの手順でOK
(926)
自宅で録画用にRX100S6が動いていたけど、最近上物が不調で再構成しなければいけなくなったので、ちょうど良い機会なので仮想化統合することにした。
仮想化のベース環境は、VMware vSphere ESXi 6.0 Update1にした。 ESXiはデバイスパススルーの実績も多いので録画サーバとしてはちょうど良い。
ハードウェアとしては、サーバはDL360G7でXeon L5630が1本、メモリは8GBx6 UDIMMに(一部ML110G7から流用)
ドライブは240GB SSDx2と2TB HDDx2の構成でオンボードのP410iからミラーリング、キャプチャはPT3とPX-W3PEの2本刺し。
アプリケーション的にはTVRockとTVTestの昔ながらの構成。
(1565)
IX2215のリモートアクセス用L2TPの接続数をZabbixで監視するためにアイテムを作成してみた。
IX2215はSNMPv2cでZabbixから監視されている状態で、SNMP Deviceテンプレートでディスカバリ。
今回は手っ取り早く、計算アイテムで作成。 L2TPトンネルはTunnel10.0~19.0に設定されているとから、
1 |
count("ifOperStatus[Tunnel10.0]",#1,1,"eq")+count("ifOperStatus[Tunnel11.0]",#1,1,"eq")+count("ifOperStatus[Tunnel12.0]",#1,1,"eq")+count("ifOperStatus[Tunnel13.0]",#1,1,"eq")+count("ifOperStatus[Tunnel14.0]",#1,1,"eq")+count("ifOperStatus[Tunnel15.0]",#1,1,"eq")+count("ifOperStatus[Tunnel16.0]",#1,1,"eq")+count("ifOperStatus[Tunnel17.0]",#1,1,"eq")+count("ifOperStatus[Tunnel18.0]",#1,1,"eq")+count("ifOperStatus[Tunnel19.0]",#1,1,"eq") |
ifOperStatusはSNMPのインタフェイス動作ステータスに結びついたキーで、アップしていると1、ダウンしていると2になる。
countはcount(キー名、期間、値、条件)形式で、キーの指定期間(#数値形式は回数、数値形式は秒数)の記録を条件・値で評価した数を返すので、この場合は直近1回のアップ状態をカウントして、10-19番のトンネルを合算しているだけ。
キーは、ifOperStatusみたいな書き方だと、アイテムを書いているホストの他のアイテムのキー指定で、IX2215:ifOperStatusみたいに書いて、指定ホスト(この場合IX2215)のキーを指定できる。
たいした物じゃ無いけど、Zabbixの計算アイテムをはじめて作ったので、書式がイマイチわからなかったのでメモしておく。
(739)
最近のネットワーク構成の流れで、IX2215がセンタルータと化している。
ローカルからの利用では、IXからVPSまでIPSecトンネル(Tunnel1.0)を張って利用しているけど、L2TPでIXにダイアルアップ(Tunnel10.0)するとIPSecトンネルを通らずに、グローバルIPをそのまま通ってしまう。
Tunnel1.0へのポリシーはGE2.0のポイントに張っているから、Tunnel10.0は見た目上、GE2.0ネットワークのIPに割り当てられているものの、トンネルインタフェイス自体はインタフェイスの一つなので、そちらにもTunnelを経由する経路を入れておかないといけない。
この場合はポリシールーティングを設定すれば、Tunnel1.0を通ることが出来る。
1 2 3 4 5 6 7 8 9 10 11 12 |
ip access-list toSakura permit ip src any dest さくらIP ip access-list toOnamae permit ip src any dest お名前IP route-map rmap-tunnel permit 10 match ip address access-list toSakura set interface Tunnel1.0 ! route-map rmap-tunnel permit 20 match ip address access-list toOnamae set interface Tunnel2.0 ! interface Tunnel10.0 ip policy route-map rmap-tunnel |
ルートマップで、VPN経由のインタフェイス指定を作ってやって、L2TPが入ってくるインタフェイスにそのルートマップを割り当てている。
(680)
自宅のネットワークもサーバもIPv6化したことだし、外部からもIPv6で繋がるようにと、手持ちのXperia IIJmio SIM挿しをIPv6接続する。
IIJmioはIPv4v6(デュアル)に対応しているので、LTE端末でAPNのプロトコルモードをIPV4V6にすればそのままv6も繋がるんだけど、ドコモモデルスマホはプロトコルモードがグレーアウトされていてIPv4固定で編集できない。 SIMフリー端末なら普通に切り替えられるんだけど。
この場合、端末のRootを取ってあれば、以下の方法でIPV4V6に切り替えることが出来る。
SQLite Editorを導入
SQLite Editorを開いて、SuperSUでRootアクセスを許可
/data/data/com.android.providers.telephony/databases/telephony.dbを開く
carriersテーブルを開き、IIJmioのAPNの行をeditで開く
protocolカラムのIPと言う値をIPV4V6に書き換えて閉じる
テーブル一覧画面で、メニューからExportを実行
※このツールでは編集内容をファイルに書き込む操作、いわゆるSaveがExportだ
このあと、再起動してやって設定画面のAPNのプロトコルモードがIPv4またはv6とか、IPv4/v6になっていれば切り替えできているのでIPv6サイトに繋いでみて確認する。 このブログの右バナーのConnected:via IPv6表示でも確認できる(現在の接続に応じてIPv4とv6が変わります)
(2239)
QnapとかSynologyの中級以上のモデルのNASだと単体でクラウドに転送してバックアップしたり出来るけど、ちょっと古いモデルとか低価格モデルでは機能提供されていなかったり、パフォーマンス不足でまともに動かず利用できない。
我が家でもSynologyの最新Atomモデルは普通にスタンドアローンで出来るけど、ちょっと型の古いQnapだと動くけど数百KB/sしかでないとかで使い物にならないので、さくらのVPSに主導させてやることにした。
基本構成としては、さくらのVPSと自宅のIX2215にIPSec VPNを張って、その上でNASをVPSにマウントして、rcloneでGoogleDriveに同期してしまうと言う方法。 安価なIX2025とかでも同じ設定でVPN張れるし、別記事を参考にすればRTX1000系でもOK。
まず、先の記事通り、VPSとIX2215までIPSecを張ってしまって、rcloneを導入する。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
wget http://downloads.rclone.org/rclone-v1.26-linux-amd64.zip unzip rclone-v1.26-linux-amd64.zip cp ./rclone-v1.26-linux-amd64/rclone /usr/sbin/ rclone config #ここから対話形式 No remotes found - make a new one n) New remote q) Quit config n/q> n #新規接続先を作成 name> googledrive #接続先の識別名 What type of source is it? Choose a number from below 1) amazon cloud drive 2) b2 3) drive 4) dropbox 5) google cloud storage 6) swift 7) hubic 8) local 9) onedrive 10) s3 11) yandex type> 3 #driveがGoogleDriveの事 Google Application Client Id - leave blank normally. client_id> #不要 Google Application Client Secret - leave blank normally. client_secret> #不要 Remote config Use auto config? * Say Y if not sure * Say N if you are working on a remote or headless machine or Y didn't work y) Yes n) No y/n> n #Yだとローカル(VPS上)でブラウザを開いて認証、通常はクライアント側で操作するのでN If your browser doesn't open automatically go to the following link: https://accounts.google.com/o/oauth2/auth?~秘密のコード~ Log in and authorize rclone for access Enter verification code> #上のリンクをローカルのブラウザにコピペして開いて、Googleの認証画面でDriveを使うアカウントで認証許可し、発行された認証コードをここにコピペする。 #あとは確認でOKして保存 |
これでrcloneの導入が完了。
このrcloneはユーザ単位で設定される(~/.rclone.confに保存)
1 2 3 4 |
mkdir /mnt/smb mount -t cifs //192.168.0.100/share /mnt/smb -o ro,user=user,password=password rclone mkdir googledrive:/nasbackup rclone copy /mnt/smb/ googledrive:/nasbackup/ --drive-chunk-size=2M --bwlimit=2M |
SambaでNASの共有をマウントして、rcloneコマンドでバックアップ用ディレクトリをGoogleDrive上に作って、共有ディレクトリを丸ごとコピーしてしまう。
drive-chunk-sizeは転送単位設定で、デフォルトだと細切れ過ぎてスピードが出ないので1M以上の値を設定する。 bwlimitで帯域を制限する(共有サービスだから他のユーザを圧迫しないようにするのと、家のアクセス回線の帯域も圧迫しないようにするため)
適当に自動バックアップスクリプトを書くなら・・・
1 2 3 4 5 6 7 8 9 10 |
SHARE="//192.168.0.100/share" CREDENTIAL="~/.smbcredential" MOUNTED=`mount | grep $SHARE | wc -l` if [ $MOUNTED -eq 1 ]; then echo "target mounted." else mount -t cifs $SHARE /mnt/smb -o ro,credentials=$CREDENTIAL rclone copy /mnt/smb googledrive:/nasbackup/ --drive-chunk-size=2M --bwlimit=2M umount $SHARE fi |
こんな感じだろうか。
当該の共有がマウント済みなら前回のバックアップが終わっていないと判定して終了させる扱いをいれて、あとは普通にマウント、バックアップ、アンマウントを行うだけ。
~/.smbcredentialの中身は
username=nas user
password=nas password
みたいに、NASのSMBユーザとパスワードを書いておく(マウントオプションでuser/passwordを書くと他のユーザがmountコマンドを打ったときに丸見えになるので、他のユーザが見えないパーミッションのcredentialsファイルに設定する)
(740)
ここ数年、個人メインのVPSとしてGMOクラウドVPSを使っていたんだけど、昨年末に問題が発生してさくらのVPSに帰ってきました。
今回発生した問題は、GMOクラウドVPSのストレージメンテナンスの実施後にストレージが完全に破損していて使えなくなっていたという問題。
この問題自体は、あちらのメンテナンスでFSを解析しながらメンテナンス実施したんだと思うんだけど、そのFSが完全に破損していてリンクがおかしい(ファイルが見えない、ディレクトリも見えないところがあって、見えるファイルの中身も全然違うファイルのアドレスにリンクされている)
まぁ、壊れたのは仕方ないんだけど、そのあとのサポートがどうにもならない。 まず、問い合わせをしても3日間返事無し、電話で再度連絡するけど1次受付後にやっぱり返事が来ない(せめて、こういう内容を受け付けました、程度の連絡はあっても良いだろう・・・)
むかついてTwitterでつぶやいたら公式垢から連絡があって、そのあとサポートからメールが来たんだけどその内容もおかしい。 こっちの言ったことを理解できていない。
そして、VPSのコンパネで仮想マシンを操作しようとすると起動停止などが応答しないから操作できない。 数十分遅れで動いて、提供されているリカバリーモードというLiveLinuxで立ち上がったけど、これがゴミ仕様。 起動した瞬間SSHが立ち上がっているにもかかわらず、ひどい脆弱なパスワード認証のrootアクセスが許可されているので、立ち上がった瞬間にログインしてパスワード変更しないと超危険という、サーバ業者が提供して良いレベルのイメージじゃ無い。
結局、あきれ果ててさくらに移そうと解約申し込みを入れるとコンパネが操作できない(解約予約するとコンパネが無効にされるアホ仕様)
何度問い合わせてもまともに対応しないし、対応したとしても話が通じない、 提供しているサービス内容にも問題があって、普通に利用できる品質には達していないと言う判断で今回、メインを移動しました。
あとは、職場で契約してるヤツも移行してやろうと年明け早々、サーバ移管の提案を作成中です。
気に入って長年使ってきただけに残念だけど、GMOクラウドのサービスは二度と利用しないでしょう。 障害が発生するのは仕方ないけど、サポートする能力も努力もしていない会社なんでごめんです。
(454)