Wolfgang Strasser has started a series on the new scale-out functionality in SQL Server Integration Services 2017. First, his introduction:
In the past, SSIS package executions were only able to run on the server that hosted the Integration Services server itself. With the rising number and requirements of more and more package executions sometimes the resources on the server ran short. Addressing this resource shortage custom scale out functionality was implemented that allowed package executions to be transfered to other “worker” machines in order to distribute execution load. With SQL Server 2017, this functionality is built into an shipped with SSIS 2017.
Before I am diving deeper into SSIS Scale Out I would like to discuss some basic vocabulary in the field of scalability.
Then, he describes the scale-out architecture:
The master is managing the available workers and all the work that is requested for execution in the scale out topoloy.
-
The master manages a list of (active) workers
-
The master gets the instructions from clients
-
The master knows the current state of work (queued jobs, running jobs, finished jobs, ..)
If you’re familiar with other distributed computing systems, this follows a similar path.