What is a Site Switch?
Each Salesforce instance is built and maintained in two geographically separate locations. An instance is actively served from one location (the active site) with transactions replicating in near real-time to the other completely redundant location (the ready site). This infrastructure model allows us to switch the location of the active site for maintenance, compliance, and disaster recovery purposes, which is referred to as a site switch.
During site switch instance would remain the same instance however will be supported from the secondary data center. During Site switch org will be in read only mode for about an hour.
Email IP addresses Whitelist -
Important Actions
A. Subscribe to Trust Notifications to know when site switches happen.
B. Follow Salesforce infrastructure best practices by not restricting access to Salesforce IP ranges, removing hard-coded references, and by setting your DNS timeout value to 5 minutes (default setting).
C. Customers with Live Agent/SOS custom clients should ensure those clients can properly handle redirects to the new active site, otherwise a disruption to your Live Agent service can occur. The best method to avoid these issues is to handle the SwitchServer response and use the 'newUrl' property for the request that resulted in this response and all subsequent requests thereafter.
Frequently Asked Questions
1. How does Salesforce communicate a site switch?
Planned site switches are posted to the maintenance calendar on our Trust site at status.salesforce.com. If we need to perform a site switch during an incident to bring an instance back online, the incident record on status.salesforce.com will be updated to reflect that information. Sign up for Trust Notifications regarding your instance to receive maintenance notification emails (reminders, starting, updates, and completed) as well as incident notification emails (new, updates, resolved, and root cause). See the Trust Notification User Guide for more information on how to sign-up for these emails.
2. How long does a site switch take?
Currently, site switches can take approximately one hour to complete. As we improve our operational processes through practice and reiteration, our goal is reduce this window. For planned site switches, we post the anticipated site switch activity window to Trust.
3. Can I opt out of a site switch?
Individual orgs cannot be opted out of a site switches. Due to the multi-tenant architecture of our infrastructure, all orgs on the instance must undergo a site switch at the same time.
Planned site switches are only scheduled during preferred system maintenance windows. We ask that you plan maintenance activities for your Salesforce org (software upgrades, integration changes, etc.) outside of the preferred system maintenance windows.
4. Will I be able to access my org during a site switch?
During planned site switches, your org should be available in read-only mode for the duration of the site switch activity unless otherwise stated. If, for any reason, read-only mode will not be available, the maintenance record on Trust will be updated to reflect the expected impact to availability.
5. What actions are required to prepare for a site switch?
If you already follow our infrastructure best practices by not restricting access to Salesforce IP ranges and setting your DNS timeout value to 5 minutes (default setting), a site switch should be seamless to your users.
Otherwise, if you are restricting access to certain IP ranges or data centers, then update your network settings to include the complete list of Salesforce IP ranges in order to avoid any unintended service disruptions following a site switch. And if you control your DNS timeout values set, then you may need to refresh your DNS cache and restart any integrations following the maintenance.
6. How does a site switch impact previously scheduled activities (weekly exports, Apex jobs, etc.) and Apex callouts?
Ongoing activities will be paused prior to the site switch and resumed following the site switch. Activities scheduled during the site switch will start following the site switch.
A small subset of Apex, Batch Apex, REST API, SOAP API, and Bulk API jobs started prior to the site switch may return an error following the maintenance window. If you receive an error resulting from a previously scheduled job following the maintenance window, restarting the job will return the expected results. We recommend rescheduling large or long-running jobs after the site switch completes for the most seamless experience.Apex callouts to external services will continue to execute during the maintenance, and since these frequently result in follow-up DML calls to the Salesforce application, you may experience issues with intended program flows as the application will be in read-only mode. We recommend preventing these callouts from executing in read-only mode. For more information on how to prevent these callouts, see Apex Callouts in Read-Only Mode.
7. How does a site switch impact Web-2-Lead, Web-2-Case, and Email-2-Case activities?
Web-2-Leads, Web-2-Cases, and Email-2-Cases that occur during the site switch will be queued and processed following the completion of the site switch.
8. Will a site switch impact Live Agent?
Yes. During a site switch, your org’s active site gets switched to the ready location, and the ready site gets switched to the active location. When this happens, the URL you use to access Live Agent/SOS changes. Chat clients and deployment code supplied by Salesforce react to this change and appropriately forward HTTP requests to the new endpoint, but some third-party or custom applications, including Live Agent custom REST clients, may not. These custom applications will not be able to find your account on your previous instance and will likely fail.
To minimize impact to your Live Agent/SOS implementation, follow best practices and ensure your Live Agent custom REST client can properly redirect requests to a new instance of the Live Agent service following any maintenance involving a move for your org. The best method to avoid these issues with your custom client (which, again, will not automatically direct requests to the correct endpoint) is to handle the SwitchServer response and use the 'newUrl' property for the request that resulted in this response and all subsequent requests thereafter. For more information on updating your custom client and testing, read the article, How to update your Live Agent custom client when your org instance changes. This will ensure your custom client will not encounter issues after a site switch, and will provide you ample time to later update the endpoint used from the start of its execution.
For more information about Live Agent endpoints and what is meant by hard-coded Live Agent references, review the article, Live Agent server (endpoint URL) has changed and now Live Agent Chat is no longer working.
9. How does a site switch impact ongoing sandbox refreshes?
Sandbox refreshes that are not completed prior to the site switch will be stopped. The sandbox refresh will restart (not resume) following the site switch. In addition, customers will not be able to initiate a sandbox refresh during the site switch.
No comments:
Post a Comment