• 技術専門家が設計・構築/移行まで一気通貫で伴走してくれる OCLS • 既にOCI環境でデータセンタ基盤を整備していた • 専用線FastConnectも構築済み O C I • DB処理で現行と同じ処理性能を維持 (変えることのリスク懸念) • クラウド環境でのライセンスコストアップを回避 DBMS 03 POINT 02 POINT 01 POINT
CI( O CVS ) 自社 DC 仮想サーバ基盤 仮想サーバ基盤 販管システム E S X i vSphere E S X i vSphere 共通基盤 HCX FastConnect VM VM VM サーバ移送 F W LB HCX L2延伸 HCXバージョンの サポート期間が短い (1年間)ので要注意
CI( O CVS ) 自社 DC 仮想サーバ基盤 仮想サーバ基盤 E S X i vSphere E S X i vSphere HCX FastConnect VM VM VM VM VM VM Front Back Front Back VM トロンボーン現象 F W LB HCX L2延伸 VM
CI( O CVS ) 自社 DC 仮想サーバ基盤 仮想サーバ基盤 E S X i vSphere E S X i vSphere HCX FastConnect VM VM VM VM VM VM Front Back Front Back VM F W LB HCX L2延伸 VM MON 有効化
O C V S ) 自 社 D C 仮想サーバ基盤 仮想サーバ基盤 FastConnect VM HCX VM HCX L 2 延 伸 O C I ( O C V S ) 自 社 D C 仮想サーバ基盤 仮想サーバ基盤 FastConnect VM HCX VM HCX L 2 延 伸 OFF ON クローン 移行対象サーバの選定 • バックエンドのバッチ処理システムでダウン タイムを許容できる • 移行失敗時の切り戻しも長時間となる • 数TBの容量規模のサーバでvMotion移行が 失敗したので、代替策としてBulk移行を採用 ➡ 約10TBのDBサーバを選定 うまくいかなかったこと • DBサーバのDB停止に想定以上の時間を要し、 再起動のタイムアウト制限でエラーとなった ➡ 回避策として、DB停止したうえで実行 ※ 移行速度が平均300Mbps~400Mbpsの環境で、3~23.5時間の移行実績(ディスク容量によって差がある)
I ( O C V S ) 自 社 D C 仮想サーバ基盤 仮想サーバ基盤 FastConnect VM HCX VM HCX L 2 延 伸 O C I ( O C V S ) 自 社 D C 仮想サーバ基盤 仮想サーバ基盤 FastConnect VM HCX HCX L 2 延 伸 削除 ON クローン VM 移行対象サーバの選定 • 公開サービスシステムでダウンタイムを許容 できない • 1~2TBまでの容量規模のサーバを選定 • vMotion移行できなかった(原因特定できず) サーバの代替策としてRAV移行を採用 ➡ 基本的には、vMotion移行を採用 うまくいかなかったこと • 特になし ※ 移行速度が平均300Mbps~400Mbpsの環境で、1~5時間の移行実績(ディスク容量によって差がある)
• 自社DC(オンプレ)のHCXがESXのDRS機能により自動vMotionされている • vMotion時にHCXのネットワークが一時的に切れる ➡ オンプレ経由の外部通信が切れる 対 策 • HCXをDRS機能の対象から外す設定を行う 事 象 原 因 対 策 E S X i オンプレ仮想サーバ基盤(クラスタ) HCX VM VM E S X i E S X i VM VM VM VM VM 負荷UP 負荷UP VM VM DRS DRS機能により自動vMotion HCXが自動vMotion されないように DRS対象から外す
• システムが稼働している(DBがある)データストアのI/O帯域は480MB/s • 同時に実行していたバックアップ処理が約450MB/sを使用しており、データ抽出処理に必要な I/O帯域を確保できていない 対 策 • バックアップ処理で使用するI/O帯域を制限する(100MB/sを上限に制限) • データストアのI/O帯域をアップする ➡ 最大値の1,280MB/s(年間コストが約32万円アップ) 事 象 原 因 対 策 O C V S O C I Object Storage BKデータを別の DataStoreにする ことはできない… BKデータ DBデータ BK VM VM VM ※ BK:バックアップ DataStore バックアップ処理
• クライアントシステムからのファイル送信回数が多い(1ファイルずつ送信している) • クライアントシステムからのSQL発行回数が多い(1件ずつSQL発行している) ➡ 自社DC(オンプレ)処理よりも通信経路が長くなることで顕在化する 対 策 • ファイルを圧縮してまとめて送信し、OCVS上のサーバで解凍する • SQL*Loaderを使用して、OCVS上のサーバで一括DB登録/更新する 事 象 原 因 対 策 O C I ( O C V S ) 自 社 D C 業 務 拠 点 クライアント システム 1万回超えのファイル送信 業 務 拠 点 O C I ( O C V S ) 自 社 D C クライアント システム SQL 40万回超えのSQL発行/結果返却 OCVS移行の前に アプリ改修する ケースがある