サイト切り替えとは:
各 Salesforce インスタンスは 2 つの地理的に異なる場所に構築され、維持されています。インスタンスは一方の場所 (有効サイト) から有効に提供され、ほぼリアルタイムで、もう一方の完全に冗長な場所 (予備サイト) でトランザクションが複製されます。サイト切り替えとは、インスタンスの有効サイトと予備サイトの場所を入れ替えて、予備サイトを新しい有効サイト、有効サイトを新しい予備サイトにすることです。インスタンス名は変更されません。このインフラストラクチャモデルを使用することで、メンテナンス、コンプライアンス、障害回復のために有効サイトの場所を切り替えることができます。
重要な作業
A. サイト切り替えが実施された場合に通知を受け取れるように Trust Notifications に登録してください。
B. Salesforce インフラストラクチャのベストプラクティスに従って、Salesforce の IP 範囲、または該当する場合は Government Cloud の IP 範囲へのアクセスを制限せず、ハードコード化された参照を削除し、DNS タイムアウト値をデフォルト設定の 5 分間に設定します。
C. Live Agent/SOS カスタムクライアントが新しい有効サイトへのリダイレクトを適切に処理できることを確認します。適切に処理できないと、Live Agent サービスが機能しなくなる場合があります。これらの問題を回避する最適な方法は、SwitchServer 応答を処理し、この応答の要求と後続の要求で新しい newUrl プロパティを使用します。詳細は、質問 9 を参照して下さい。
D. サイト切り替えの後にメールログを表示する場合、メンテナンス実施時間の前にメールログを要求します。詳細は、質問 12 を参照してください。
E. クライアントエンドポイント (PC など) とインターネットサービスプロバイダ (ISP) で DNS キャッシュを更新していることを確認します。場合によっては、Salesforce に起因しない潜在的なログインの問題を緩和するために、DNS テーブルの更新を ISP に依頼する必要があります。
よくある質問
1. サイト切り替えは、どのような方法で通知されますか?
継続的サイト切り替えのスケジュールは、Trust のメンテナンスカレンダー (status.salesforce.com) に掲載され、維持されます。特定のインスタンスがスケジュールに含まれているかどうかを確認するには、https://status.salesforce.com でインスタンスをクリックするか、https://status.salesforce.com/status/<インスタンス> (例: https://status.saleforce.com/instances/NA146) にアクセスして、そのインスタンスのメンテナンスカレンダーを確認します。お客様には Trust Notification に登録して、サイト切り替えを含むメンテナンスのスケジュールやメンテナンス中の更新情報を受信することをお勧めします。Trust Notification への登録方法の詳細は、https://trust.salesforce.com/ja/trust/trust-notification-user-guide を参照してください。
インシデント発生中にインスタンスをオンラインに戻すためにサイト切り替えを実行する必要があった場合、status.salesforce.com のインシデント記録が更新されてその情報が反映されます。ご利用のインスタンスに関する Trust Notification にサインアップすると、メンテナンス通知メール、メンテナンスリマインダー、および進行状況の更新 (開始通知と完了通知を含む) を受信できます。Trust Notification では、インシデント通知および解決の進行状況に関する更新も提供されます。これらのメールにサインアップする方法についての詳細は、「Trust Notification User Guide (Trust Notification ユーザガイド)」を参照してください。
2. サイト切り替えにはどの程度の時間を要しますか?
この新しいプログラムでは、サイト切り替えは約 20 分で完了します。その間、インスタンスの完全なダウンタイムが発生する可能性があります。メンテナンス中にダウンタイム期間がいつ発生するかは正確に示すことができないため、サイト切り替え中インスタンスは使用不可とみなすことをお勧めします。計画サイト切り替えについては、サイト切り替え作業の予想所要時間を Trust に掲載しています。Government Cloud のお客様の場合、所要時間は 45 分です。
3. サイト切り替えは以前はリードオンリーで 30 分間のメンテナンスでしたが、インスタンスは 20 分間完全にダウンするようになっています。この変更の理由は?
Salesforce では、安定したシステムの可用性、パフォーマンス、信頼性を通じてお客様の成功を実現することを最優先に考えています。そのために、Salesforce は既存のプロセスを継続的に評価し、すべてのサービスの全体的な効率と提供を改善する方法を探しています。サイト切り替えでの目的は、サイト切り替えに要する時間を短縮することによって、予期しないインシデントや長時間メンテナンスの際に、よりシームレスにアクティビティを利用できるようにすることです。
20 分間のメンテナンス中は、インスタンスで完全なダウンタイムが発生します。そのため、サイト切り替え中はインスタンスを使用不可とみなすことをお勧めします。
4.サイト切り替えから除外されるように指定することはできますか?
個別の Salesforce 組織をサイト切り替えから除外することはできません。Salesforce のインフラストラクチャではマルチテナントアーキテクチャを採用しているため、インスタンス上のすべての組織に対して同時にサイト切り替えを行う必要があります。
計画サイト切り替えは、優先システムメンテナンス実施時間内にのみスケジュールされます。お客様の Salesforce 組織のメンテナンス作業 (ソフトウェアのアップグレード、インテグレーションの変更など) は、優先システムメンテナンス実施時間以外にスケジュールしていただきますようお願い申し上げます。
5.サイト切り替え中に Salesforce 組織にアクセスできますか?
計画サイト切り替えの作業中は、お客様の組織はご利用いただけなくなります。サイト切り替えは約 20 分で完了するようになりました。サイト切り替え中はインスタンスを使用不可とみなすことをお勧めします。
6.サイト切り替えの準備に必要な作業は?
お客様が Salesforce インフラストラクチャのベストプラクティスに従って、Salesforce IP 範囲へのアクセスを制限せずに、DNS タイムアウト値をデフォルトの 5 分間に設定し、ハードコード化された参照を Live Agent 実装に含めていない場合、サイト切り替えはシームレスに実行されます。
アクセス先を特定の IP 範囲またはデータセンターに制限している場合は、サイト切り替え後に意図しないサービス中断を避けるために、Salesforce の IP 範囲の完全なリストが含まれるようにネットワーク設定を更新してください。また、DNS タイムアウト値セットを制御している場合は、メンテナンス後に DNS キャッシュを更新し、すべてのインテグレーションを再起動することが必要になる場合があります。
7.サイト切り替えによって、以前からスケジュールされていたアクティビティ (ウィークリーエクスポート、Apex ジョブ、Apex コールアウトなど) はどのような影響を受けますか?
継続中のアクティビティは、サイト切り替えの開始後にインスタンスを使用できないために停止されます。サイト切り替え中にスケジュールされたアクティビティは、サイト切り替えの完了後に実行されます。外部サービスへの Apex コールアウトは、メンテナンス期間中に失敗することが予想されます。最良の結果を得るには、サイト切り替えが完了してから、大きなジョブや長時間実行ジョブのスケジュールを変更することをお勧めします。
8.サイト切り替えによって、Web-to-リード、Web-to-ケース、メール-to-ケースのアクティビティはどのような影響を受けますか?
サイト切り替え中に発生したメール-to-ケースのアクティビティはキューに入れられ、サイト切り替えの完了後に処理されます。Web-to-リードおよび Web-to-ケースは一時停止され、メンテナンスの完了後に再開されます。
9.サイト切り替えは Live Agent に影響しますか?
はい。サイトの切り替え中は、Salesforce 組織の有効サイトが予備サイトの場所に、予備サイトの場所が有効サイトの場所に切り替わります。その後、Live Agent/SOS へのアクセスに使用される URL が変わります。Salesforce から提供されるチャットクライアントとリリースコードは、この変更に対応して HTTP 要求を新しいエンドポイントに適切に転送しますが、一部のサードパーティまたはカスタムアプリケーション (Live Agent カスタム REST クライアントなど) はそのように動作しません。これらのカスタムアプリケーションは、以前のインスタンスでアカウントを見つけることができず、失敗する可能性が高くなります。
Live Agent/SOS 実装への影響を最小限に抑えるには、ベストプラクティスに従って、組織の移動を伴うメンテナンスの後に Live Agent カスタム REST クライアントが Live Agent サービスの新しいインスタンスに要求を適切にリダイレクトできるようにします。カスタムクライアントでこれらの問題 (要求が自動的に適切なエンドポイントに転送されない) を回避する最適な方法は、SwitchServer 応答を処理し、この応答の要求と後続のすべての要求で newUrl プロパティを使用します。カスタムクライアントの更新とテストについての詳細は、「組織インスタンスの変更時に Live Agent カスタムクライアントを更新する方法」を参照してください。
Live Agent エンドポイント、およびハードコード化された Live Agent 参照についての詳細は、「Live Agent サーバ (エンドポイント URL) が変更された後、Live Agent チャットが機能しない」を参照してください。
10.サイト切り替えによって、Sandbox の更新はどのような影響を受けますか?
未完了の Sandbox の更新は、サイト切り替え前に停止されます。サイト切り替え後に Sandbox の更新は再起動されますが、再開されません。お客様は、サイト切り替え中に Sandbox の更新を開始することはできません。
11.サイト切り替えによって、メール送信は影響を受けますか?
サイト切り替え後、メールは切り替え前と異なる IP を持つメール転送エージェント (MTA) から送信されます。MTA は評価が確立されていることを確認してください。メール配信は影響を受けませんが、アクセス制御リスト (ACL) や許可リストによるメールリレーを使用している場合は例外です。詳細は、「許可すべき Salesforce の IP アドレスとドメイン」を参照してください。
必要に応じて、ACL および許可リストでメールを中継するための IP があることを確認してください。Salesforce でメールリレーを使用していることを確認するには、[設定] に移動して「メールリレーの有効化」を検索します。[有効] チェックボックスがオンになっている場合、メールはメールリレーを使用して設定内に記載されているホストに配信されます。
12.サイト切り替え後にメールログを表示するには、メンテナンスの前にメールログを要求しておく必要がありますか?
はい。切り替え後にメールログを表示するには、メンテナンス実施時間の前にメールログを要求します。メールログを要求するには、「メールログのリクエスト」を参照してください。メールログを要求したら、メールログはデータベースに保存され、サイト切り替えメンテナンス時に移行されます。以前のデータセンターからのメールログは、サイト切り替え後には抽出できなくなります。
メールログには、メンテナンス後の短い期間 (最大 30 日間)、メールが送信されたと表示されているのに、メールの最終的な宛先が含まれていない場合があります。新しい有効サイトの IP は、大量のトラフィックを処理する前に、インターネットでの評価を確立する必要があります。
000389427

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.