107 lines
5.4 KiB
Markdown
107 lines
5.4 KiB
Markdown
# Specifics of the Sharepoint Connector
|
|
|
|
Normally, you will have different configurations if you want multiple Sharepoint Connectors. This makes the *nsp* somewhat special:
|
|
|
|
## Multi Instance HA Sharepoint Connector
|
|
|
|
This sample shows how to setup a sharepoint connector with multiple instances having **different** configurations for archival, but with **High Availability** on the retrieval side.
|
|
|
|
SharePoint is one of the few components for which is is quite common to have multiple instances instead of replicas. Replicas would include, that the configuration for all pods is identical. However, you might want to have multiple configurations as you also have multiple sharepoint sites you want to archive.
|
|
|
|
Running multiple instances with ingress enabled leads to the question, what the context path is for each instance. It cannot be the same as the load balancer would not be able to distinguish between them and thus refuses to add the configuration object - leading in a deadlock situation.
|
|
|
|
So *nplus* defined different context paths if you have multiple instances:
|
|
|
|
- sharepointa on `/nscale_spca`
|
|
- sharepointb on `/nscale_spcb`
|
|
- sharepointc on `/nscale_spcc`
|
|
- sharepointd on `/nscale_spcd`
|
|
|
|
If you only run one instance, it defaults to `/nscale_spc`.
|
|
|
|
## HA on retrieval
|
|
|
|
Once archived, you might want to use all instances for retrieval, since they share a common retrieval configuration (same nappl, ...). So in order to gain High Availability even across multiple instances, there are two options:
|
|
|
|
1. You turn off the services and ingresses on any sharepoint instance but sharepointa. Then you switch sharepointa's service selector to *type mode*, selecting all pods with type `sharepoint` instead of all pods of component `sharepointa`. Then you can access this one service to reach them all.
|
|
2. You can turn on the *clusterService*, which is an additional service that selects all `sharepoint` type pods and then adds an extra ingress on this service with the default context path `nscale_spc`
|
|
|
|
However, in both scenarios, beware that the sharepoint connector can only service one context path at a time, so you will need to change the context path accordingly.
|
|
|
|
## Sample for solution 1
|
|
|
|
On the instance, define the following:
|
|
|
|
```
|
|
components:
|
|
# -- First, we switch the default SharePoint OFF
|
|
sharepoint: false
|
|
|
|
# -- Then we enable two sharepoint instances to be used with different configurations
|
|
sharepointa: true
|
|
sharepointb: true
|
|
|
|
sharepointa:
|
|
service:
|
|
# -- Switching the service to "type" makes sure we select not only the component pods (in this case all replicas of sharepointa)
|
|
# but rather **any** pod of type sharepoint.
|
|
selector: "type"
|
|
ingress:
|
|
# -- The default contextPath for sharepointa is `nscale_spca` to make sure we have distinguishable paths for all sharepoint instances.
|
|
# however, in this case we re-use the service as cluster service and die ingress as cluster ingress, so we switch to the general
|
|
# contextPath, as if it was a single component deployment
|
|
contextPath: "/nscale_spc"
|
|
sharepointb:
|
|
service:
|
|
# -- The other SP Instance does not need a service any more, as it is selected by the cluster service above. So we switch off the component
|
|
# service which also switches off the ingress as it would not have a backing service any more
|
|
enabled: false
|
|
# -- The default contextPath for sharepointb is `nscale_spcb` to make sure we have distinguishable paths for all sharepoint instances.
|
|
# however, in this case we re-use the service as cluster service and die ingress as cluster ingress, so we switch to the general
|
|
# contextPath, as if it was a single component deployment
|
|
contextPath: "/nscale_spc"
|
|
```
|
|
|
|
|
|
## Sample for Solution 2
|
|
|
|
On the instance, define the following:
|
|
|
|
```
|
|
components:
|
|
# -- First, we switch the default SharePoint OFF
|
|
sharepoint: false
|
|
|
|
# -- Then we enable two sharepoint instances to be used with different configurations
|
|
sharepointa: true
|
|
sharepointb: true
|
|
|
|
sharepointa:
|
|
clusterService:
|
|
# -- This enabled the cluster service
|
|
enabled: true
|
|
# -- the cluster Ingress needs to know the context path it should react on.
|
|
contextPath: "/nscale_spc"
|
|
ingress:
|
|
# -- we turn off the original ingress as the common context path would block the deployment
|
|
enabled: false
|
|
# -- The default contextPath for sharepointa is `nscale_spca` to make sure we have distinguishable paths for all sharepoint instances.
|
|
# however, in this case we re-use the service as cluster service and die ingress as cluster ingress, so we switch to the general
|
|
# contextPath, as if it was a single component deployment
|
|
contextPath: "/nscale_spc"
|
|
sharepointb:
|
|
clusterService:
|
|
# -- on the second SharePoint Instance, we **disable** the cluster service, as it is already created by sharepointa.
|
|
enabled: false
|
|
# -- however, we need to set the context path, as this tells the networkPolicy to open up for ingress even though we switch die Ingress off in the
|
|
# next step
|
|
contextPath: "/nscale_spc"
|
|
ingress:
|
|
# -- we turn off the original ingress as the common context path would block the deployment
|
|
enabled: false
|
|
# -- The default contextPath for sharepointb is `nscale_spcb` to make sure we have distinguishable paths for all sharepoint instances.
|
|
# however, in this case we re-use the service as cluster service and die ingress as cluster ingress, so we switch to the general
|
|
# contextPath, as if it was a single component deployment
|
|
contextPath: "/nscale_spc"
|
|
```
|