BCP-620 · Question #105
Currently there is one BlackBerry Enterprise Server located in London and one located in New York. High availability is already a requirement and now management is formulating a disaster recovery…
The correct answer is B. Install a new BlackBerry Enterprise Server configured for high availability at each site with its own. Option B is correct because when WAN links suffer from performance issues, each site must be self-sufficient - having its own independent BES with its own local database and high availability configuration ensures that neither London nor New York depends on cross-WAN…
Question
Currently there is one BlackBerry Enterprise Server located in London and one located in New York. High availability is already a requirement and now management is formulating a disaster recovery plan. What would be a recommended strategy if the WAN links suffer from performance issues? (Choose one)
Options
- AInstall a new BlackBerry Enterprise Server configured for high availability at each site and share the
- BInstall a new BlackBerry Enterprise Server configured for high availability at each site with its own
- CConfigure each BlackBerry Enterprise Server for high availability and with mirrored databases as that
- DInstall a new BlackBerry Enterprise Server configured for high availability on a clustered server each
- EConfigure BlackBerry Enterprise Server on a cluster server
How the community answered
(26 responses)- A19% (5)
- B69% (18)
- C8% (2)
- D4% (1)
Explanation
Option B is correct because when WAN links suffer from performance issues, each site must be self-sufficient - having its own independent BES with its own local database and high availability configuration ensures that neither London nor New York depends on cross-WAN communication to maintain service. This isolation means a degraded or failed WAN link does not cascade into a service outage at either site.
Why the distractors fail:
- A involves sharing a resource (likely a database or infrastructure) across sites, creating a cross-WAN dependency that defeats the purpose when WAN performance is the exact problem.
- C uses mirrored databases - database mirroring across a poor-performing WAN introduces replication lag and potential split-brain scenarios, making it unreliable for disaster recovery.
- D references a clustered server per site, but clustering traditionally requires low-latency, high-bandwidth links between nodes; stretching clusters across a problematic WAN is an anti-pattern.
- E only addresses local clustering with no disaster recovery strategy and ignores the WAN performance constraint entirely.
Memory tip: Associate WAN performance problems with "cut the cord" - when the link between sites is unreliable, each site needs to operate as a completely independent island. If an answer implies sharing anything across the WAN, it's wrong in this context.
Topics
Community Discussion
No community discussion yet for this question.