Resilient Operations and Disaster Recovery with OutsideView
OutsideView supports a variety of methods whereby it can operate very resiliently. These mechanisms can be implemented as a convenience, or as an automatic means of Disaster Recovery.
Session Level Resiliency
The host/port address field in an OutsideView session file can contain a series of values. Should the first host/port combination not be available, OutsideView will automatically try to connect to the second, then the third, and so on. This provides automatic ‘failover’ for a variety of conditions, whether it is accessing alternate TELSERV ports on the same host, or connecting to an alternate host in a Disaster Recovery situation. Each time the OutsideView session is restarted or reconnected, it will attempt to connect to specified addresses in order – providing automatic ‘failback’.
Enterprise-wide Resiliency
The Enterprise form of OutsideView uses a Windows shared folder as a central data repository or ‘hub.’ OutsideView Enterprise end-users also have their own local data storage. Each time an end-user instance of OutsideView Enterprise is started, it automatically synchronizes its local data with the central hub. This reduces the need for frequent software distributions and redistributions since it provides a near real-time, highly sophisticated alternative, supporting multiple profiles.
Upon each end-user startup of OutsideView, the program accesses these network folders as a central resource, dynamically refreshing:
- License checkout
- User or Group (aka Profile) membership
- Workgroup definitions, per Profile
- Session Configurations, per Profile
- Custom Color or Toolbar settings, per Profile
- Service name, per individual user
- Automatic OutsideView Update
- User Permissions settings, per Profile
- Location of alternative failover/failback point
This centralized administration and distribution of software configurations and versions obviously provides large-scale OutsideView installations with huge benefits in operational ease, reduced support, responsiveness to changing conditions, etc.
It is natural for prospects to ask, “What’s the downside of the Enterprise architecture?” A frequent concern is whether the central shared folder, or ‘hub’ constitutes a single point of failure. The answer is, “No.”
Operational Resiliency / Disaster Recovery
Windows servers, even Windows server clusters, go down more frequently than NonStop systems.
Therefore, OutsideView contains logic wherein the file structure comprising the central ‘hub’ can be duplicated in an alternate location, and supports automatic failover and failback between the two locations, whether this is a momentary interruption of service, or a longer-term disaster recovery situation.
This capability is easily implemented. Merely replicate the ‘hub’ to another location (with identical properties). Then create, in the primary hub, a file identifying the alternate location. The end-user copy of OutsideView will automatically acquire and retain that information locally. Thereafter, if that end-user copy of OutsideView cannot access the primary hub, it automatically fails over to the alternate location. Each restart of that copy of OutsideView will cause it to retry the primary location, providing automatic failback capability.
Some people, unimpressed with Windows availability, might ask, “What if both locations are down at the same time?” After all, if both Windows servers are unavailable, neither can respond to OutsideView end-user requests to access the OutsideView Enterprise central resource (shared folder). We have designed OutsideView Enterprise to compensate for even that situation…
Each time an OutsideView Enterprise end-user successfully starts Outside View, the end-user’s workstation:
1. Dynamically identifies end-user’s Profile membership
2. Dynamically obtains a serial number from a central license pool
3. Dynamically validates end-user application software is the appropriate level a. (Downloads latest version if necessary)
4. Dynamically downloads Profile-appropriate OutsideView configuration files to the end-user’s workstation, for local execution.
5. Locally logs the date of the successful access of the central resource.
6. Acquires the latest failover location.
In the event, neither OutsideView central resource is available (for whatever reason, whether networking, VPN, server difficulty, folder permissions, etc.) when the end-user starts OutsideView on their local workstation, OutsideView will:
1. Display a warning message:
2. Determine whether that workstation’s last successful access of the central resource was within the allowable period (7 days for OutsideView with classic licensing, a configurable period for OutsideView with SQL licensing).
a. IF within the allowable period, OutsideView will start, using cached information, obtained during the last successful access.
b. IF the last successful access is older than the allowable period, OutsideView will display a second error message and shut down.
Summary
- In the event a host connection is not successfully established, OutsideView can automatically “fail over” to a next listed host or port. OutsideView will also automatically “fail back.”
- The Enterprise ‘hub’ can exist in duplicate locations. If the primary location is unavailable for any reason, the OutsideView end-use copy will automatically connect with the alternate location.
- Once the primary location comes back up, the OutsideView end-use copy will automatically revert to the primary location upon its next restart.
If you have any questions, please contact support@crystalpoint.com