Files
nplus/samples/sharepoint/README.md
2025-01-24 16:18:47 +01:00

5.4 KiB

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"