This article shows you how to change Login and KODiAC Data Replication Policies.
KODiAC Cloud Services coordinates protection, access, availability, integrity, auditing and reporting through coordination with the host :Foundation Client requests. Details are purposely hidden from end-user consideration, though administrative considerations apply for the distribution and accessibility of managed content.
This article shows you how to manage global Login Policy and associated KODiAC Replication Policies that allow you to retain controls over where content is stored, and how it is accessed.
KODiAC Replication UI
Privileged Organization Users can access the KODiAC Replication UI from the notification icon's context menu of the same name:
NOTE: KODiAC Replication cannot be specialized when using an Individual Account; Content will remain with the Home Server, and Remote Login is permitted through redirection as noted below.
The top left of the dialog shows the Home Server, the default Server Set for all Organization KODiAC cloud content - whether :Recover data, KODiAC-specific configuration details, audit data, etc.
At present, the Home Server is defined when you first create your Organization (and thus the Administrator Account), regardless of whether you used the Registration Email, Sign-Up, or Account Migration.
The Active Server shows your Login Session's connection to KODiAC Cloud Services (and associated TCP port), in this case ssp.secdefini.com. The sections that follow explain, in more detail, how the :Foundation Client and KODiAC negotiate the given end-result.
KODiAC Archive and Retention Policy
The remainder of the dialog's left side provides information about the Organization's :Recover Archive (when applicable) and associated Retention Policy, with buttons that redirect to the UI displays used to make configuration changes. For example, use Offline to display the Offline Archive (:xRecovery) UI.
Active Server Set Resolution
The right side of the dialog allows you to modify Login Policy to suit your needs. This determines the target Server Sets to which your Organization Users can connect.
Though completely invisible to end-users, the Login procedure carries out the following:
- The :Foundation Client resolves the nearest Server Set with DNS queries that resolve accordingly
- The :Foundation Client connects to KODiAC Cloud Services hosted by the resulting Server Set
- The :Foundation Client submits Login Identity used for KODiAC to Authenticate
- KODiAC acquires the Organization's Login Policy to determine how to proceed
- KODiAC accepts the current connection, redirects as per Policy, or rejects the request
The location from which an Account connects, together with the associated Login Policy, determines how Login Session's connection is finalized. The end-result is the Active Server value shown at the top left.
Using Login Policy
Enable Login Policy by checking Global Login/ Reg. This allows you to enable individual Server Sets that can be used by authorized Organization Accounts located in other regions.
When Login Policy is not enabled (Global Login/ Reg is not checked), :Foundation Client login proceedings first contact the nearest Server Set (as noted in the previous section) however, once authorized for Login, connectivity is redirected to the Home Server for ongoing processing - no matter where the :Foundation Client is located. This can create not-insignificant latency when performing certain operations (such as data Restore).
If, however, you enable Login Policy, the :Foundation Client will connect to the local Server Set if/ when it's enabled otherwise redirect to the Home Server.
Let's consider an example. Assume you do not have Login Policy enabled, and your Organization's Home Server is as in the given dialog, above - uswest.secdefini.com. If your office was in the San Francisco Bay Area or anywhere on the West Coast, connectivity would be low-latency and suitable for your needs. If however you traveled to Tokyo and attempted to Login, KODiAC would redirect your client to connect directly to uswest.secdefini.com. Though this is a viable and functional configuration, operations like Restoring :Recover content will proceed with added latency.
In some cases, this is necessary based on Regulatory stipulations and corporate Policy. Note that, in the near future, this will be enhanced to permit or deny Login from non-enabled Server Sets, precluding the noted case instead of redirecting back to USWest.
Take the same example but with the Login Policy as shown in the dialog - in that case, when you Login from Tokyo, because that region (APAC1) is enabled, you would connect locally to apac1.secdefini.com. Requests would then be handled with local :Foundation Client/ KODiAC connectivity, which performs measurably better than a remote redirect.
What happens, in this case, when you attempt to Restore :Recover content? This is where Replication Policy comes into play; the two are purposely decoupled though operation resolves to coordinated results, described in the next section.
Using Replication Policy
Without Replication Policy, all Organization content gets stored in your Home Server (Sets). When Replication Policy is enabled, a couple things change.
First, :Recover content is replicated to the target Region. This may be confusing because, when you first enable Replication, your Regional Replication control is unchecked, i.e. if you have a Home Server of USWest, the United States Regional Control isn't checked by default. In that case, content is not replicated between USWest and USEast even though both may be enabled for Login Policy. When you check the associated United State Region, it enables East->West and West->East :Recover replication, which is useful when Organization Peers attempt to Restore peer content (permitted) and/ or if your team members travel back and forth between coasts. This is especially useful when you travel to the Midwest and want the lowest latency connection - it can and will vary depending on present Internet dynamics and other factors.
As you may have guessed, choosing other regions then replicates :Recover content to the respective Region. Note that Server Sets are independent from :Recover Regional content, so the mapping is not entirely straightforward though access is equally, "low-latency, high-performance". Ultimately, you're choosing whether or not :Recover content will be made available to your users traveling and logging into Server Set resources in the target Region.
As a result, the Regional Replication options are not enabled if you do not permit Login Policy to one or more of the associated Server Sets.
Login and Replication Policy enable/ disable are committed after you make a change and assert a prompt to confirm your intent.
Changes to Login Server Sets and Replication Regions are however committed when you choose OK. If you choose Cancel, those changes are discarded - though of course any adjustment to enable/ disable overall Policy will be retained.
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to email@example.com, and our staff will respond to your needs as soon as possible.
In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.
This article was updated w/ v9.8.1 of the :Foundation Client