SDPF クラウド/サーバー 基盤バージョンアップ作業について
クラウド/サーバー, ネットワーク
2022年3月4日 (2022年12月6日:更新)
平素よりSmart Data Platform(以下SDPF)をご利用いただき誠にありがとうございます。
SDPFにおいて、基盤設備の老朽化に伴い大規模なメンテナンス作業を計画しております。
メンテナンス作業の日程、影響等は以下の内容となります。
※メンテナンス影響はお客さまの利用しているメニュー毎にそれぞれ異なります。事前に弊社よりメールにて通知されるメンテナンス情報の記載内容をご確認ください。
※2022年4月に、以下の周知内容を変更いたしましたのでご確認いただきますようお願いいたします。
(変更点)
– リソース強制停止の開始時間を「1時以降」に変更
– 作業工程と影響時間の図を変更
(追記)
-FAQ欄の通知方針を詳細化
※2022年5月19日に、以下の周知内容を追記いたしましたのでご確認いただきますようお願いいたします。
(追記)
– FAQ欄2件(メンテナンス後に発生する可能性のある事象について)
※2022年10月18日に、以下の周知内容を追記いたしましたのでご確認いただきますようお願いいたします。
(追記)
-サービス影響⑤ロードバランサー(NetScaler VPX)の(5)OS上の時刻がずれる事象によるサービス影響
※2022年12月6日に、以下の記載変更をいたしましたのでご確認いただきますようお願いいたします。
(記載変更)
-完了済みのメンテナンス日程を斜線表記に変更
メンテナンス作業対象リージョン
JP1 グループA/B、JP2 グループA/B
メンテナンス作業日時
影響するメニュー情報は、メンテナンスの約1か月前に通知されるメールをご確認ください。下記に記載の開始/終了時間は現時点で予定となっております。
実施時間等について変更がある場合、適宜本ページにて更新を行いますので、ご確認をお願い致します。
JP2(大阪第5データセンター/大阪第1データセンター)
2022年5月3日(火)22時00分 〜 06時00分(JST) グループB
2022年8月25日(木)22時00分 〜 06時00分(JST) グループA
JP1(埼玉第1データーセンター)
2022年8月11日(木)22時00分 〜 06時00分(JST) グループB
2022年12月31日(土)22時00分 〜 06時00分(JST) グループA
対象メニュー
仮想サーバー
サーバーインスタンス
クラウド/サーバー ネットワークセキュリティ
ファイアウォール(vSRX)、ファイアウォール(Brocade 5600 vRouter)
Managed Firewall、Managed UTM、Managed WAF
クラウド/サーバー ローカルネットワーク
ロードバランサー(NetScaler VPX)、Managed Load Balancer
サービス影響
①サーバーインスタンス
(1)ポータル・APIの参照/操作系影響
該当サービスにおける作業対象リージョン・グループにおいてポータル/API経由した以下の操作をご利用いただくことができません。
ポータルサイト、APIのサービス停止時間は00時40分 〜 02時55分(JST)となります。
※停止時間は前後することがあります。
・仮想サーバーの操作
・ルートディスク・ボリュームディスクの操作
(2)通信影響
作業対象リージョン・グループの各作業時にサービスの停止を行います。停止時間は約80分程度を予定しており、約80分程度はお客様へ提供させて頂いておりますサービスを停止致します。
22時からリソース借用時間としますが、ポータルサイトやAPIの閉塞作業ついては0時以降に実施いたします。お客様作業にてリソース停止を行う場合は0時までに実施いただくようお願いいたします。1時以降は強制停止となり、サービス側で停止/起動(Suspend/Resume(※1))を行います。そのため、停止時間の間、OS上の時刻がずれる事象が発生致しますため、極力お客様での停止をお願い致します。
時刻がずれていた場合、NTPサービスの再起動もしくはOSの再起動の実施にて回復させることが可能です。
※1.Suspendはサーバーインスタンスを一時停止することになります。(OSのShutdownやサーバーインスタンスのPowerOffではございません。)Resumeは一時停止されたサーバーインスタンスを再開させることになります。
事前にお客様にてリソースを停止してからメンテナンス作業が始まるまでの時間と、メンテナンス終了後にお客様にてリソースを起動するまでの停止時間は含まれておりませんのでご留意ください(下図参照)。
また、メンテナンス終了後にサービス側で起動(Resume)作業を実施する対象リソースは、メンテナンス作業前にサービス側にて停止したリソースのみとなります。
(3)推奨する対応方針
メンテナンス作業前にお客様にて異なるグループ間で冗長構成を組んでいただくことでメンテナンス時間中のサービスの完全断を回避いただくことができます。
②Oracle、SQL Serverをご利用中のサーバーインスタンス
(1)ポータル・APIの参照/操作系影響
①サーバーインスタンスの「ポータル/APIへの参照/操作系影響」をご確認ください。
(2)通信影響
①サーバーインスタンスの「通信影響」をご確認ください。
(3)推奨する対応方針
DBを保護するため、仮想サーバーのサービス停止前に Oracle やSQL Serverがインストールされた仮想サーバーリソースをお客様にて停止してください(強く推奨)。
上記を実施しない場合データ不整合など起こる場合がございます。
メンテナンス作業前にお客様にて異なるグループ間で冗長構成を組んでいただくことでメンテナンス時間中のサービスの完全断を回避いただくことができます。
③ファイアウォール(vSRX)
(1)ポータル・APIの参照/操作系影響
作業対象リージョンの全てのグループ(グループC/Dを含む)において、当社が提供するカスタマーポータル/APIを経由した各種操作をご利用いただくことができません。
ポータルサイト、APIのサービス停止時間は00時40分 〜 02時55分(JST)となります。
※停止時間は前後することがあります。
(2)通信影響
作業対象リージョン・グループの各作業時に対象となるサービスの停止を行います。停止時間は約80分程度を予定しており、約80分程度はお客様へ提供させて頂いておりますサービスを停止致します。
22時からリソース借用時間としますが、ポータルサイトやAPIの閉塞作業ついては0時以降に実施いたします。お客様作業にてリソース停止を行う場合は0時までに実施いただくようお願いいたします。1時以降は強制停止となり、サービス側で停止/起動を行います。
メンテナンス終了後にサービス側で起動作業を実施する対象リソースは、メンテナンス作業前にサービス側にて停止したリソースのみとなります。
(3)推奨する対応方針
メンテナンス作業前にお客様にて異なるグループ間で冗長構成を組んでいただくことでメンテナンス時間中のサービスの完全断を回避いただくことができます。
また、事前にVRRPのPriority値を変更し、作業対象グループではないデバイスをMASTERにすることで、作業対象グループのリソース停止時のMASTER切り替わりによる通信断を回避することができます。
NTT Comでリソースの停止をする場合においては、メンテナンス終了後にNTT Comにてリソースを起動した後、OS上の時刻がずれる事象が発生する場合がございます。お客様にてリソースの再起動を実施いただくことで本事象を回復することが可能です。
以下、冗長構成のお客様に推奨する作業手順 ※ ()内は手順実施者
A. 事前にお客様でリソースの停止を実施する場合
MASTER切り替え(お客様) → 作業対象グループのリソース停止(お客様) → メンテナンス開始(NTT Com) → メンテナンス終了(NTT Com) → 作業対象グループのリソース起動(お客様) → MASTER切り替え(お客様)
B. NTT Comでリソースの停止を実施する場合
MASTER切り替え (お客様) → 作業対象グループのリソース停止(NTT Com) → メンテナンス開始(NTT Com) → メンテナンス終了(NTT Com) → 作業対象グループのリソース起動(NTT Com) → 作業対象グループのリソースの再起動(お客様) → MASTER切り替え(お客様)
(4)メンテナンス終了後の正常性確認方法
カスタマーポータルより、対象リソースのモニタリングステータス、ログインステータス、仮想サーバーステータスが全て「ACTIVE」であることをご確認ください。
④Managed Firewall、Managed UTM、Managed WAF
(1)ポータル・APIの参照/操作系影響
作業対象リージョンの全てのグループ(グループC/Dを含む)において、当社が提供するカスタマーポータルを経由した各種操作をご利用いただくことができません。
ポータルサイトのサービス停止時間は00時00分 〜 04時05分(JST)となります。
※停止時間は前後することがあります。
(2)通信影響
作業対象リージョン・グループの各作業時に対象となるサービスの停止を行います。停止時間は約80分程度を予定しており、約80分程度はお客様へ提供させて頂いておりますサービスを停止致します。
22時からリソース借用時間としますが、ポータルサイトやAPIの閉塞作業ついては0時以降に実施いたします。お客様作業にてリソース停止を行う場合は0時までに実施いただくようお願いいたします。1時以降にサービス側でリソースを強制停止し、メンテナンス終了後にサービス側で起動を行います。
お客様のManaged Firewall/UTM/WAFがどのグループで構築されているかの確認方法はKnowledge Centerのチュートリアル「メニュー変更/プラン変更(HA構成)」をご確認ください。
(3)その他影響
サーバーインスタンス同様、Managed FW、UTM、WAFにおいてもOS上の時刻がずれる事象が発生します。
Managed FW、UTM、WAFでは1時間周期で時刻同期を実施しているため、時刻がずれる事象は1時間以内に解消します。
Managed FW、UTM、WAFで出力されるログに記載される時刻はOS上の時刻であるため、OS上の時刻がずれている間はログに記載される時刻は実際の時刻とずれた時刻になります。
OS上の時刻がずれる事象はお客様作業にてデバイスを事前に停止いただくことで防ぐことができます。
・Managed FW・UTMの停止、起動方法
Operation画面の”サービス”タブを押下 → “ワークフロー”を押下 → “UTM Port Management”を押下 → “Stop/Start UTM”を押下
・Managed WAFの停止、起動方法
Operation画面の”サービス”タブを押下 → “ワークフロー”を押下 → “WAF Port Management”を押下 → “Stop/Start WAF”を押下
(4)推奨する対応方針
HA構成プランをご利用いただくことで、メンテナンス時間中のサービスの完全断を回避いただくことができます。
⑤ロードバランサー(NetScaler VPX)
(1)ポータル・APIの参照/操作系影響
作業対象リージョンの全てのグループ(グループC/Dを含む)において、当社が提供するカスタマーポータル/APIを経由した各種操作をご利用いただくことができません。
ポータルサイト、APIのサービス停止時間は00時40分 〜 02時55分(JST)となります。
※停止時間は前後することがあります。
(2)通信影響
作業対象リージョン・グループの各作業時に対象となるサービスの停止を行います。停止時間は約80分程度を予定しており、約80分程度はお客様へ提供させて頂いておりますサービスを停止致します。
22時からリソース借用時間としますが、ポータルサイトやAPIの閉塞作業ついては0時以降に実施いたします。1時以降にサービス側でリソースを強制停止し、メンテナンス終了後にサービス側で起動を行います。
(3)推奨する対応方針
メンテナンス作業前にお客様にて異なるグループ間で冗長構成を組んでいただくことでメンテナンス時間中のサービスの完全断を回避いただくことができます。
また、事前にVRRPのPriority値を変更し、作業対象グループではないデバイスをMASTERにすることで、作業対象グループのデバイス停止時のMASTER切り替わりによる通信断を回避することができます。
NTT Comでリソースの停止、メンテナンス終了後にNTT Comにてリソースを起動した後、OS上の時刻がずれる事象が発生する場合がございます。お客様にてリソースの再起動を実施いただくことで本事象を回復することが可能です。
以下、冗長構成のお客様に推奨する作業手順 ※ ()内は手順実施者
MASTER切り替え (お客様) → 作業対象グループのリソース停止(NTT Com) → メンテナンス開始(NTT Com) → メンテナンス終了(NTT Com) → 作業対象グループのリソース起動(NTT Com) → 作業対象グループのリソースの再起動(お客様) → MASTER切り替え(お客様)
(4)メンテナンス終了後の正常性確認方法
カスタマーポータルより、対象リソースのステータスが「稼働中」であることをご確認ください。
(5)OS上の時刻がずれる事象によるサービス影響
シスログ転送機能を利用されている場合
(影響)
シスログに記載されるタイムスタンプの時刻がずれた状態となります。
(対処方法)
リソースの再起動を実施していただき、OS上の時刻ずれを解消していただく必要がございます。
Cookie Insert によるセッション維持機能を利用されている場合
(影響)
・OS上の時刻ずれが発生した結果、Cookie Insert にて挿入される Cookieの有効期限が OSの時刻を元にするため、過去時刻となってしまう可能性があります。
・過去時刻のCookieを受け取った クライアント (ブラウザなど) は すぐにExpire すると想定されるため、Cookie Insert が正常に動作しない状況となります。
(対処方法)
本格対処:
リソースの再起動を実施していただき、OS上の時刻ずれを解消していただく必要がございます。
暫定対処:
・メンテナンス前にVRRPのPriority値を変更し、作業対象グループではないデバイスをMASTERに切り替えます。
・メンテナンス前にCookie Insert の有効期限を十分に長い期間 (最大1440秒) に変更します。
※時刻ずれが発生した場合でも、Cookieの有効期限を十分に長い期間に設定することで、Cookie Insert を動作させることが可能です。
※しかし、Cookieの有効期限を長く設定すると、クライアントが同じ負荷分散先で長く固定されてしまうこととなるため、恒久的な対応としては本格対処であるリソースの再起動を実施し、Cookieの有効期限を元に戻すことを推奨いたします。
⑥Managed Load Balancer
(1)ポータル・APIの参照/操作系影響
作業対象リージョンの全てのグループ(グループC/Dを含む)において、当社が提供するカスタマーポータル/APIを経由した各種操作をご利用いただくことができません。
ポータルサイト、APIのサービス停止時間は00時40分 〜 02時55分(JST)となります。
※停止時間は前後することがあります。
(2)通信影響
作業対象リージョン・グループの各作業時に対象となるサービスの停止を行います。停止時間は約80分程度を予定しており、約80分程度はお客様へ提供させて頂いておりますサービスを停止致します。
22時からリソース借用時間としますが、ポータルサイトやAPIの閉塞作業ついては0時以降に実施いたします。1時以降にサービス側でリソースを強制停止し、メンテナンス終了後にサービス側で起動を行います。
お客様のManaged Load Balancerがどのグループで構築されているかの確認方法はKnowledge Centerのチュートリアル「ロードバランサーの基本操作(作成・変更・削除等)」をご確認ください。
(3)推奨する対応方針
HA構成プランをご利用いただくことで、メンテナンス時間中のサービスの完全断を回避いただくことができます。
(4)メンテナンス終了後の正常性確認方法
カスタマーポータルより、対象リソースのモニタリングステータスが「ACTIVE」であること、また、ゾーン / グループ(プライマリー)が「ACTIVE」になっていることをご確認ください。
お客さまへの通知
本メンテナンス作業の対象となるお客さまについては各メンテナンス作業日の1か月前を目途に弊社保守よりメールにて個別に通知させて頂きます。
※尚、メンテナンス作業日の1か月前以内に当該のリージョンにてメニュー増設利用をされると、メンテナンス作業の対象となり、影響を受ける場合がございます。予めご了承ください。
FAQ
Q.サービス停止の必要性について
A.本バージョンアップ作業はSDPFのBackend基盤ストレージ(ストレージサービスではありません)のソフトウェア・アップデート作業となります。Backend基盤ストレージはGroup内で冗長化構成ではございますが、本バージョンアップでは冗長化されているNodeにおいて、同時再起動が必要となります。ストレージベンダとも協議を行いましたが、再起動に伴う大規模な基盤メンテナンスを実施させて頂くこととなりました。
Q.スケジュールの個別相談は可能か
A.個別のスケジュール調整については受け付けておりません。
Q.作業開始/終了の連絡を個別でもらうことは可能か
A.メール送信等の個別の通知は行いません。
RSS登録をいただくことで、各リージョンの運用ステータス変更が発生した際に通知が飛びますので、RSSフィードの登録をお願いいたします。
運用ステータスの変更は下記3回のタイミングで実施予定で、それぞれRSS配信を行います。併せて、故障・メンテナンス情報(サービス稼働状況)ページの当該メンテナンスのイベントの詳細に作業進捗を表示いたします。
・NTTComにて強制停止したリソースの起動完了
・その他ポータル/APIの開放完了
・セキュリティポータル/APIの開放完了
https://ecl.ntt.com/service-status/
Q.利用者側での事前作業はあるのか
A.可能な限りメンテナンス前にサービスを停止下さい。
Q.利用者側での事後作業はあるのか
A.メンテナンス前にお客様にて停止したリソースの起動作業と正常性確認の実施をお願い致します。
Q:バージョンアップ作業後にボリュームがオフラインとなったり、インターフェイスのデバイス名が変更されてしまった。
A:以下に記載の対処内容をお試しください。
https://sdpf.ntt.com/faq/virtual-server-35/
Q:作業完了後にリソースを起動した際にntpdが停止したが、なぜか?
A:OSの時刻がずれるとntpdが動作するため、OSに影響のある強制停止(suspend)処理が、ntpd停止のきっかけになった可能性がございます。