Dernière mise à jour le 3 mars 2022
Qu'est-ce qu'un basculement de site ?
Chaque instance Salesforce est construite et gérée à deux emplacements géographiquement séparés. Une instance est activement servie à partir d'un emplacement (le site Actif) et les transactions sont répliquées en temps quasi réel vers l'autre emplacement, qui est totalement redondant (le site Prêt). Un basculement de site signifie que les emplacements du site Actif et du site Prêt d'une instance sont échangés, le site Prêt devenant le site Actif, et inversement. Le nom de l’instance ne change pas. Ce modèle d'infrastructure nous permet de basculer l'emplacement du site Actif afin de procéder à des opérations de maintenance, de conformité et de reprise après sinistre.
Actions importantes
A. Abonnez-vous aux Notifications Trust pour connaître les dates de basculement de site.
B. Suivez les meilleures pratiques pour l'infrastructure Salesforce en ne limitant pas l'accès aux plages d'adresses IP Salesforce, aux plages d'adresses IP Government Cloud (le cas échéant), en retirant les références codées en dur et en définissant votre valeur d'expiration DNS sur 5 minutes (paramètre par défaut).
C. Les clients avec des clients personnalisés de Live Agent/SOS doivent s’assurer que ces clients peuvent gérer correctement les redirections vers le nouveau site Actif pour éviter une interruption du service Live Agent. Afin d'éviter ce problème, la meilleure solution consiste à traiter la réponse du SwitchServer et à utiliser la propriété 'newUrl' pour la requête qui a entraîné cette réponse et pour toutes les requêtes successives. Pour plus d'informations, reportez-vous à la question 8.
D. Si vous souhaitez consulter vos journaux de messagerie après un basculement de site, demandez-les avant la période de maintenance. Pour plus d'informations, consultez la question 11.
E. Il est important que les clients actualisent leur cache DNS à la fois sur les points de terminaison du client (par exemple PC) et auprès de leur fournisseur de services Internet (ISP). Dans certains cas, il faut demander au fournisseur de service Internet d'actualiser ses tableaux DNS pour éviter les problèmes de connexion potentiels non imputables à Salesforce.
Foire aux questions
1. Comment Salesforce communique-t-elle un basculement de site ?
Les basculements de site planifiés sont publiés dans le calendrier de maintenance de notre site Trust à l'adresse status.salesforce.com. Si nous devons procéder à un basculement de site pour remettre une instance en ligne en cas d'incident, l'enregistrement de l'incident est mis à jour sur le site status.salesforce.com afin de refléter cette information. Pour recevoir les e-mails de maintenance (rappels, débuts de maintenance, mises à jour et fins de maintenance) ainsi que les e-mails sur les incidents (nouveaux, mis à jour, résolus et causes profondes), inscrivez-vous aux notifications Trust correspondant à votre instance. Pour plus informations sur l'abonnement à ces e-mails, reportez-vous à Présentation du basculement de site.
2. Quelle est la durée d'un basculement de site ?
Actuellement, les basculements de site durent environ vingt minutes. Pour les basculements de site planifiés, nous publions les dates à l'avance sur le site Trust.
3. Est-ce possible de se retirer d'un basculement de site ?
Les organisations individuelles ne peuvent pas se retirer d'un basculement de site. En raison de l'architecture mutualisée de notre infrastructure, toutes les organisations d'une instance doivent basculer en même temps.
Les basculements de site sont planifiés uniquement durant le Calendrier des fenêtres de maintenance Salesforce préférées. Nous vous invitons à planifier les activités de maintenance de votre organisation Salesforce (mises à niveau logicielles, changements d'intégration, etc.) hors des périodes de maintenance système préférées.
4. Puis-je accéder à mon organisation pendant un basculement de site ?
Votre organisation n'est pas disponible pendant un basculement de site. Les basculements de site durent environ 20 minutes. Nous recommandons aux clients de considérer l’instance comme indisponible pendant le basculement de site.
5. Quelles sont les mesures à prendre pour préparer un basculement de site ?
Si vous appliquez nos meilleures pratiques relatives à l'infrastructure en ne limitant pas l'accès aux plages d'adresses IP Salesforce et en définissant votre valeur d'expiration DNS sur 5 minutes (paramètre par défaut), un basculement de site devrait se faire de façon harmonieuse pour vos utilisateurs.
Si vous limitez l'accès à certaines plages IP ou à certains centres de données, mettez à jour vos paramètres réseau pour inclure la liste complète des plages IP Salesforce afin d'éviter toute interruption inattendue du service suite à un basculement de site. Si vous contrôlez les valeurs d'expiration de votre DNS, l'actualisation de votre cache DNS et le redémarrage de toutes les intégrations peuvent être nécessaires après l'opération de maintenance.
6. Quel est l'impact d'un basculement de site sur les activités déjà planifiées (exportations hebdomadaires, tâches Apex, etc.) et sur les appels externes Apex ?
Les activités en cours sont interrompues avant le basculement et reprises après le basculement. Les activités planifiées pendant un basculement de site démarrent après la maintenance.
Quelques tâches démarrées avant le basculement de site, notamment Apex, Apex par lot, API REST, API SOAP et API de transfert en masse, peuvent renvoyer une erreur suite à une opération de maintenance. Si vous recevez une erreur correspondant à une tâche déjà planifiée après un basculement de site, redémarrez-la pour obtenir les résultats attendus. Nous recommandons de replanifier les tâches longues ou volumineuses une fois le basculement de site terminé pour obtenir la meilleure expérience possible.
L'exécution des appels Apex à des services externes se poursuit pendant la maintenance. Nous recommandons d'empêcher l'exécution de ces appels externes pendant une période de maintenance. Pour plus d'informations, consultez Callouts Limits and Limitations.
7. Quel est l'impact d'un basculement de site sur les activités Web vers piste, Web vers requête et E-mail vers requête ?
Les activités Web vers piste, Web vers requête et E-mail vers requête exécutées pendant un basculement de site sont mises en file d'attente et traitées après l'opération de maintenance.
8. Un basculement de site affecte-t-il Live Agent ?
Oui. Lors d'un basculement de site, le site Actif de votre organisation est basculé vers un emplacement préparé, et ce site Prêt est basculé vers l'emplacement actif. Pendant cette opération, l'URL que vous utilisez pour accéder à Live Agent/SOS change. Les clients du chat et le code de déploiement fournis par Salesforce réagissent à cette modification et transmettent correctement les requêtes HTTP au nouveau point de terminaison, ce qui n'est pas toujours le cas avec certaines applications tierces ou personnalisées, notamment les clients personnalisés REST Live Agent. Ces applications personnalisées ne trouvent pas votre compte dans l’instance précédente et peuvent échouer.
Pour limiter l'impact sur votre implémentation Live Agent/SOS, suivez les meilleures pratiques et assurez-vous que votre client personnalisé REST Live Agent peut rediriger correctement les requêtes vers la nouvelle instance du service Live Agent après une maintenance impliquant le déplacement de votre organisation. Afin d'éviter ce problème avec votre client personnalisé (qui ne dirige pas automatiquement les demandes vers le point de terminaison approprié), la meilleure solution consiste à traiter la réponse du SwitchServer et à utiliser la propriété 'newUrl' pour la requête qui a entraîné cette réponse et pour toutes les requêtes successives. Pour plus d'informations sur la mise à jour de votre client personnalisé et effectuer des tests, lisez l'article Comment mettre à jour votre client personnalisé Live Agent lorsque l'instance de votre organisation change. Cela garantira que votre client personnalisé ne rencontre pas d’erreur après un basculement de site. Cela vous donnera également le temps nécessaire pour mettre à jour ultérieurement le point de terminaison utilisé depuis le début de son exécution.
Pour plus d'informations sur les points de terminaison de Live Agent et la signification des références Live Agent codées en dur, lisez l'article Live Agent server (endpoint URL) has changed and now Live Agent Chat is no longer working (en anglais).
9. Quel est l'impact d'un basculement de site sur les actualisations d'organisation sandbox en cours ?
Les actualisations d'organisation sandbox qui ne sont pas terminées le basculement de site sont interrompues. Les actualisations sandbox redémarrent (ne reprennent pas) après la maintenance. En outre, les clients ne peuvent pas initier une actualisation sandbox pendant un basculement de site.
10. Un basculement de site affecte-t-il les envois d'e-mails (par exemple vers les opérateurs mobiles ou Office 365) ?
Après un basculement de site, les e-mails sont envoyés à partir d'agents MTA (Mail Transport Agent) dont les adresses IP sont différentes de celles initialement utilisées pour envoyer vos e-mails. Ces MTA ont généralement une réputation établie et la remise des e-mails ne devrait pas être impactée, sauf si vous utilisez un relais de messagerie avec des listes de contrôle d'accès (ACL) et des listes d’autorisation. Dans ce cas, lisez l'article Adresses IP et domaines Salesforce à autoriser et vérifiez que les adresses IP du relais de messagerie sont utilisées dans vos listes ACL et vos listes d’autorisation. Pour déterminer si vous utilisez un relais de messagerie, accédez à Configuration dans Salesforce, puis recherchez « Activation du relais de messagerie ». Si la case Actif est sélectionnée, les e-mails sont remis à l'hôte spécifié dans les paramètres en utilisant un relais de messagerie.
11. Si je souhaite consulter mes journaux de messagerie après le basculement de site, dois-je les demander avant la maintenance ?
Vous devez demander vos journaux de messagerie avant la maintenance pour pouvoir les consulter après le basculement de site. Pour demander vos journaux de messagerie, suivez la procédure présentée dans l'article Requête de journal d'e-mails. Une fois demandés, les journaux de messagerie sont stockés dans la base de données et migrés avec votre maintenance en basculement de site. Les journaux de messagerie de votre ancien centre de données ne peuvent pas être extraits après le basculement de site.
Les journaux peuvent indiquer pendant une brève période que les e-mails ont été envoyés, mais leur destination finale n'est pas spécifiée jusqu'à 30 jours après la maintenance. En effet, les adresses IP du nouveau site actif doivent établir leur réputation sur Internet avant de pouvoir traiter des volumes importants de trafic.
12. Qu'est-ce que le programme Basculement de site continu de Salesforce ?
Pour plus d'informations sur ce programme, lisez l'article Basculement de site continu.
000387541

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.