Note: This documentation gets updated only when necessary, as the product is in sustained mode. For product updates see the Release Notes.

Farm / NLB Topologies

The following section discusses the deployment of K2 components in a Farm/NLB topology. (Due to the nature of a farm environment and its extensibility, the following is just an example of a basic farm set up.) When implementing a farm topology, configuration of Network Load balancing is required.

For best performance, K2 recommends installing the K2 web sites and web services on the same physical machine as the K2 application server components. Furthermore, when the K2 web sites and services and the K2 application server components are installed on the same physical machine, K2 recommends adding a hosts file entry to force any network communication between the K2 Websites hosted in IIS and the K2 Application server components on the same physical machine to stay within the machine boundaries. Please refer to the K2 Knowledge Base article Modifying the hosts file to improve performance for more information.

The following topology does not include integration with SharePoint. If SharePoint integration is required see the appropriate SharePoint section: SharePoint 2013, 2016 and Online or SharePoint 2010.

Farm/NLB environment with a separate SQL Server

Farm Install
User Machine	N/A
Developer Workstation	Client Tools: K2 Studio K2 for Visual Studio Additional components: K2 smartforms wizards
NLB Web and Application Server(s)	Internet Information Server (IIS): K2 blackpearl websites and K2 web services K2 smartforms runtime site K2 designer site Application Server: K2 blackpearl server
SQL	K2 database

Considerations for a Farm Install

The K2 Workspace and Web Services, K2 Designer and SmartForms Runtime sites are hosted on a common IIS server. An option is to install K2 Workspace and the K2 Web Services on a separate web server farm. This will lessen the impact of client requests through Workspace on the K2 Application Server. However, it is always recommended and preferred to keep the K2 SmartForms websites on the same physical server as the K2 application server.
Distributed Transaction Controller (DTC) must be configured properly for communications between the K2 Server and the SQL Server to function properly.
Network connection speed between the Application Server and the SQL server must be as fast as possible with as little latency as possible (physical servers should preferably be on the same Gigabit-backbone.)
It is not recommended to geographically separative the SQL Server from the application servers since this can introduce performance issues due to low bandwidth or latency between the K2 application servers and the SQL server.
The SQL Server can share physical resources with other SQL databases or SQL Server Instances on the same SQL server, or be located on an dedicated SQL server/instance, or be located on an Azure SQL DB.
- K2 recommends that SQL administrators track performance of the SQL server and address performance issues through standard Microsoft SQL Server scaling approaches.
K2 Pass-Through Authentication (PTA) or Kerberos is required to pass user credentials between physical or logical servers.
NLB can be configured by using either the operating system or specific hardware. In either case, NLB configuration should be completed before installing K2 smartforms. When installing components that will be load balanced, the installation must be performed on each machine independently.

Network Load Balancing(NLB)

Load Balancing

The machines residing in the individual Network Load Balancing (NLB) configurations must be configured prior to K2 installation. The following deployment consideration sections discuss NLB setup.

Network Load Balancing vs Clustering

NLB clusters dynamically distribute the flow of incoming TCP and UDP traffic among the cluster nodes according to a set of traffic-handling rules. NLB clusters provide a highly available and scalable platform for applications such as IIS. NLB is used for stateless Applications; i.e. those that do not rely on any state as a result of a request.

NLB and server clusters complement each other in complex architectures: NLB is used for load balancing requests between front-end Web servers while server clusters provide high availability for backend database access.

A server cluster is a collection of servers that together provides a single, highly available platform for hosting applications. Applications can be failed-over to ensure high availability in the event of planned downtime due to maintenance or unplanned downtime due to hardware, Operating System or application failures. Server clusters provide a highly available platform for applications such as SQL Servers. Server clusters are used for stateful applications that rely on some state context from one request to the next.

Server clusters provide high availability and disaster tolerance for mission-critical database management, file sharing, intranet data sharing, messaging, and general business applications. With Windows Server 2008 R2 with SP1, failover clustering allows flexibility for adding and removing hardware in a geographically dispersed cluster environment, as well as providing improved scaling options for applications. Windows Server 2008 R2 also allows server clusters to be deployed in a variety of different configurations, in particular:

Single cluster configurations with dedicated storage.
Multiple clusters on a storage area network (SAN), potentially with other Windows servers or operating systems.

In a clustered environment, the K2 Server is only supported on NLB clusters. Installing the K2 Server in a Windows server cluster environment is not supported.

Physical Network Environment and broadcast domains

Since a large installation typically uses more than one server in a load-balanced configuration, setting up the local network infrastructure can be more complex compared to a single server. This is because the Windows NLB technology causes multiple physical servers to appear as a single, logical server.

Network infrastructure must support the creation of multiple broadcast domains (virtual local area network, or VLAN) to segment incoming Web requests from the main production network. NLB broadcasts incoming traffic destined for the servers in an NLB group to all ports within their network collision domain (in this case, VLAN). In normal Web server deployment scenarios, the incoming traffic typically consists of a small number of HTTP GET requests and this may not be an issue. However, K2 and SharePoint network traffic may consist of large documents moving between servers.

As a result, it is imperative that the NLB adapters for the Web servers are not connected to the normal server network. A separate logical or physical network, such as a VLAN, must be created so the larger amount of incoming traffic is not flooded to the network ports of other servers, thereby causing performance degradation on all servers within the network, not just the Web servers.

Furthermore, traffic to and from a SharePoint site or the K2 application server involves a considerable amount of communication from the servers to the SQL database; good connectivity between them is required. It is therefore recommended that Web servers be dual-homed:

One network adapter handling the incoming requests by using NLB.
One network adapter acting as a normal server adapter to communicate to the server running SQL Server along with the other servers within the infrastructure, such as domain controllers for authentication purposes.

Installing Components in a Redundant Environment

When installing for load balancing, the installation must be performed on each machine independently. If for example the K2 Server is being installed in a NLB cluster similar to the example below, the server components must be installed on each individual machine.

The NLB cluster is configured using the operating system and should be configured prior to installing and configuring the K2 environment.

Additional Resources for NLB

NLB FAQ: http://technet.microsoft.com/en-us/library/cc725691(v=WS.10).aspx

While infrastructure changes are required by K2, each environment is different and has its peculiarities which must be taken into account. Modifying the infrastructure could have unforeseen results if the changes are not appropriately understood or managed. Given the broad spectrum of underlying infrastructure utilized, it is recommended that a panel or committee with appropriate skill in each area concerned be assembled to outline the underlying infrastructure changes and gauge the impact of the required changes.