마지막 업데이트 날짜: 2022년 3월 3일
사이트 전환이란 무엇입니까?
각 Salesforce 인스턴스는 지리학적으로 별개의 두 장소에 구축되어 유지 관리됩니다. 하나의 장소인 활성 사이트에서 인스턴스가 활발하게 제공되고 거의 실시간으로 완전히 다른 중복 장소인 준비된 사이트로 트랜잭션이 복제됩니다. 사이트 전환은 인스턴스의 활성 사이트와 준비된 사이트의 위치가 서로 바뀌어 준비된 사이트가 새 활성 사이트가 되며 활성 사이트가 새 준비된 사이트가 됩니다. 인스턴스 이름은 변경되지 않습니다. 이 인프라 모델을 사용하여 서비스 점검, 규정 준수, 재해 복구를 목적으로 활성 사이트의 위치를 전환할 수 있습니다.
중요 조치
A. 사이트 전환이 언제 진행되는지 알고 싶으면 Trust 알림에 가입하십시오.
B. Salesforce 인프라 모범 사례에 따라 Salesforce IP 범위, 해당하는 경우 Government Cloud IP 범위에 대한 액세스를 제한하지 않고, 하드 코딩된 참조를 제거하고 DNS 제한 시간 값을 5분(기본 설정)으로 설정하십시오.
C. Live Agent/SOS 사용자 정의 클라이언트가 있는 고객은 해당 클라이언트가 새 활성 사이트로의 리디렉션을 제대로 처리할 수 있는지 확인해야 합니다. 그렇지 않을 경우 Live Agent 서비스가 중단될 수 있습니다. 이러한 문제를 피할 수 있는 가장 좋은 방법은 SwitchServer 응답을 처리하고 이 응답과 이후 모든 향후 요청 결과로 생기는 요청에 'newUrl' 속성을 사용하는 것입니다. 자세한 내용은 질문 8을 참조하십시오.
D. 사이트 전환 후에 이메일 로그를 확인해야 하는 경우 서비스 점검 기간 전에 이메일 로그를 요청해야 합니다. 자세한 내용은 질문 11을 참조하십시오.
E. 고객이 클라이언트 끝점(예: PC) 및 인터넷 서비스 공급자(ISP) 모두에서 DNS 캐시를 새로 고쳐야 합니다. 경우에 따라 Salesforce에 기인하지 않는 잠재적인 로그인 문제를 완화할 수 있도록 ISP에 DNS 테이블을 새로 고칠 것을 요청해야 합니다.
자주 묻는 질문
1. Salesforce는 사이트 전환을 어떻게 전달합니까?
계획된 사이트 전환은 Trust 사이트인 status.salesforce.com에 있는 서비스 점검 캘린더에 게시됩니다. 사고 중 사이트 전환을 수행하여 인스턴스를 다시 온라인으로 가져와야 하는 경우 status.salesforce.com의 사고 레코드가 해당 정보를 반영하도록 업데이트됩니다. 서비스 점검 알림 이메일(미리 알림, 시작, 업데이트 및 완료) 및 사고 알림 이메일(신규, 업데이트, 해결 및 루트 원인)을 수신하기 위해 인스턴스와 관련된 Trust 알림에 등록하십시오. 해당 이메일 등록 방법에 대한 자세한 정보는 Trust 알림 사용자 가이드를 참조하십시오.
2. 사이트 전환에는 시간이 얼마나 걸립니까?
현재 사이트 전환이 완료되기까지 약 20분이 소요됩니다. 계획된 사이트 전환의 경우 예측되는 사이트 전환 활동 기간을 Trust에 게시합니다.
3. 사이트 전환을 거부할 수 있습니까?
개별 조직은 사이트 전환을 거부할 수 없습니다. 인프라의 다중 테넌트 구조로 인해 인스턴스의 모든 조직은 사이트 전환을 동시에 진행해야 합니다.
계획된 사이트 전환은 기본적인 시스템 서비스 점검 기간에만 예정됩니다. 기본적인 시스템 서비스 점검 기간 외에 Salesforce 조직의 서비스 점검 활동을 계획(소프트웨어 업그레이드, 통합 변경 등)하는 것이 좋습니다.
4. 사이트 전환 중 조직에 액세스할 수 있습니까?
계획된 사이트 전환 중에는 조직을 사용할 수 없습니다. 사이트 전환은 이제 약 20분 후에 완료됩니다. 고객은 사이트를 전환하는 동안 인스턴스를 사용하지 못한다고 생각하는 것이 좋습니다.
5. 사이트 전환을 준비하기 위해 필요한 조치는 무엇입니까?
Salesforce IP 범위에 대한 액세스를 제한하지 않고 DNS 제한 시간 값을 기본 설정인 5분으로 설정하여 이미 인프라 모범 사례를 따른 경우 사이트 전환이 사용자에게 원활해야 합니다.
특정 IP 범위 또는 데이터 센터에 대한 액세스를 제한한 경우 네트워크 설정에 Salesforce IP 범위의 전체 목록이 포함되도록 업데이트하여 사이트 전환 이후 예기치 않은 서비스 중단을 방지하십시오. DNS 제한 시간 값 집합을 관리하는 경우 서비스 점검 후 DNS 캐시를 새로 고침하고 통합을 다시 시작해야 합니다.
6. 사이트 전환은 이전에 예정된 활동(주별 내보내기, Apex 작업 등) 및 Apex 콜아웃에 어떻게 영향을 줍니까?
진행 중인 활동은 사이트 전환 이전에 일시 중지되고 사이트 전환 후에 다시 시작됩니다. 사이트 전환 중에 예정된 활동은 사이트 전환 후에 시작됩니다.
사이트 전환 이전에 시작된 Apex, 배치 Apex, REST API, SOAP API 및 대량 API 작업의 작은 하위 집합은 서비스 점검 기간 후에 오류를 반환할 수 있습니다. 서비스 점검 기간 후에 이전에 예정된 작업의 오류를 수신하는 경우 작업을 다시 시작하면 예상했던 결과가 반환됩니다. 가장 원활한 환경을 위해 사이트 전환이 완료된 후 대규모 작업 또는 장기간 실행 중인 작업 일정을 조정하는 것이 좋습니다.
서비스 점검 기간 중에는 외부 서비스에 대한 Apex 콜아웃이 실행되지 않습니다. 서비스 점검 기간 동안에서 해당 콜아웃을 실행하지 않는 것이 좋습니다. 콜아웃을 방지하는 방법에 대한 자세한 내용은 콜아웃 및 제한 사항을 참조하십시오.
7. 사이트 전환이 Web-2-Lead, Web-2-Case 및 Email-2-Case 활동에 어떻게 영향을 줍니까?
사이트 전환 중 발생하는 Web-2-Lead, Web-2-Case 및 Email-2-Case는 사이트 전환 완료 후에 대기열에 지정된 후 처리됩니다.
8. 사이트 전환이 Live Agent에 영향을 미칩니까?
예. 사이트 전환 중에는 조직의 활성 사이트가 준비 위치로 전환되고 준비된 사이트가 활성 위치로 전환됩니다. 이렇게 되면 Live Agent/SOS 액세스에 사용하는 URL이 바뀝니다. Salesforce가 제공하는 채팅 클라이언트와 배포 코드는 바뀐 URL에 반응하여 새 끝점으로 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 채팅은 더 이상 작동하지 않습니다 기사를 검토하십시오.
9. 진행 중인 Sandbox 새로 고침에 사이트 전환이 어떤 영향을 줍니까?
사이트 전환 이전에 완료되지 않은 Sandbox 새로 고침은 중단됩니다. Sandbox 새로 고침은 사이트 전환 후 다시 시작됩니다(재개 아님). 또한 사이트 전환 중 Sandbox 새로 고침을 시작할 수 없습니다.
10. 사이트 전환이 이메일 전송(예: 모바일 사업자 또는 Office 365)에 어떤 영향을 줍니까?
사이트 전환 후 이메일은 이전에 전송한 메일과 다른 IP가 있는 MTA(메일 전송 에이전트)에서 전송됩니다. 해당 MTA는 신뢰도가 확립되어야 하며 ACL(액세스 제어 목록) 및 허용 목록과 함께 이메일 릴레이를 사용하지 않는 한 이메일 전달에 영향을 주지 않아야 합니다. 이 시나리오에서 허용할 Salesforce IP 주소 및 도메인 기사를 확인하고 필요에 따라 ACL 및 허용 목록에 이메일을 릴레이할 IP가 있는지 살펴보아야 합니다. Salesforce에서 이메일 릴레이를 사용 중인지 확인하려면 설정으로 이동하여 "이메일 릴레이 활성화"를 검색하십시오. 활성 확인란을 선택한 경우 이메일 릴레이를 사용하여 설정 내에 표시된 호스트로 메일이 전달됩니다.
11. 사이트 전환 이후 이메일 로그를 볼 계획이라면 서비스 점검 전에 이메일 로그를 요청해야 합니까?
사이트 전환 후에 이메일 로그를 확인해야 하는 경우 서비스 점검 기간 전에 이메일 로그를 요청해야 합니다. 이메일 로그 요청 기사의 단계에 따라 이메일 로그를 요청할 수 있습니다. 이메일 로그를 요청하면 해당 로그가 데이터베이스에 저장되고 사이트 전환 서비스 점검과 함께 마이그레이션됩니다. 사이트 전환 후에는 이전의 데이터 센터에서 제공한 이메일 로그를 추출할 수 없습니다.
이메일 로그는 이메일이 전송된 것처럼 표시할 수 있지만 이메일의 최종 도착지는 서비스 점검 후 30일 이내에 포함되지 않을 수 있으며 짧은 시간 동안 공지될 수 있습니다. 많은 양의 트래픽을 전송하기 전에 IP가 새로 활성화된 사이트는 인터넷에서 신뢰도를 확립해야 하기 때문입니다.
12. Salesforce의 지속적인 사이트 전환 프로그램은 무엇입니까?
지속적인 사이트 전환 프로그램에 대한 자세한 정보는 지속적인 사이트 전환 기사를 검토하십시오.
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.