Planning Your StifleR Implementation
Last updated
Last updated
Planning for integrating StifleR into your Content Distribution System is simple. Like most technical projects however, preparation and attention to details pays dividends.
Location of the StifleR server should be considered although it is not too critical unless you have multiple geographical locations etc. in which case you may consider having multiple StifleR servers at key hub locations. More important is the spec of the server and its Network connectivity. Bear in mind that the server will have incoming and outgoing connections to all StifleR clients – sometimes all at once during a large scheduled deployment.
The following table can be used as a summarized view of the hardware requirements.
StifleR is CPU intensive. Since StifleR does not use that many threads, a higher frequency (Ghz) is recommended. We recommend at least a 2.4Ghz processor with 8 cores. Don’t forget that most CPU’s must also handle some of the Network connectivity management.
StifleR writes a lot of historical data to databases, as well as maintaining in-RAM memory objects. Since each connection and all connection data is stored in RAM a decent size of RAM is recommended but 32GB should be plenty for most installations.
StifleR saves a lot of information to ESENT databases, especially with the System Resource Tracking features enabled. Fast SSD disks are preferred for housing these Databases.
Each client has a non-managed SignalR client connection (web sockets) to the server, so if you want to run 100k clients to a single server you need to beef up the network connectivity.
If you are supporting a large number of clients, you probably want dual or quad 10Gb/s NIC’s for your StifleR server. This will ensure that the NIC’s have enough power to manage the large number of connections.
StifleR server requires Windows Server 2012 with Microsoft .NET version 4.7.2 or higher. If you wish to run StifleR on Windows server 2008 contact us first for a chat.
There are also requirements around IIS settings. Please refer to the Dashboard installation section for important information in this regard.
Multiple StifleR servers can be configured for larger enterprises so that clients can fail-over to a second server should the primary server become unavailable.
For larger installations we recommend splitting the load across several StifleR servers. For example one server per geographical region.
The server-side component (iperf3.exe) can run on any Windows OS (talk to us if you want to run it on Linux) It acts as the end point to which the StifleR Client Red Leaders send test packets. This allows the Red Leaders to accurately measure the maximum bandwidth available between the a Subnet/Location and the content source. Typically, you will install this component on a server in a central location (such as an SCCM Distribution Point) from which your clients obtain the bulk of their content. If you have a central datacenter for instance you can simply install the StifleR Beacon service onto any server at that location. The StifleR Beacon Service may be installed on the StifleR Server if required but there is no dependency on this configuration.
We recommend that http communication channels only be used in your initial high level testing. In a production environment we strongly recommend that you configure StifleR communication to be secured over https. For more information on SSL configuration, and all things certificate related, please refer to the companion document “Securing StifleR operations using SSL” which gives an overview of not only the StifleR and SignalR configuration but also how to set up the underlying Configuration Manager security environment to get you started.
The StifleR client will check through its queue of active downloads (both BITS and DO) and will prioritize them according to a locally held XML configuration file containing a set of rules that are configured centrally by the administrator and automatically distributed to clients.
This file contains a simple rule set that defines the content download jobs and the priority that the administrator has assigned to each job type. The “StifleR Rules XML Guide” is available for download from 2Pint website on the StifleR Product Page which gives details on how to create and configure the rules file. There is a default rules file copied into the ProgramData location as part of the Client installation but this is static and should only be used for initial basic testing purposes.
The clients will download the rules definition XML from a configured URL. If you wish to configure your own rules definition file or your client do not have internet access then you need to create this URL on your internal IIS server. If not then the clients will default to use one which is stored on the 2Pint website.
SignalR can be used in a variety of client platforms. This section describes the system requirements for using SignalR in web browsers, Windows desktop applications, Silverlight applications, and mobile devices.
When StifleR’s SignalR driven Dashboards are hosted in IIS, the following versions and configurations are supported.
IIS 10
IIS 8, 8.5 or IIS 8 Express
IIS 7 and 7.5. Support for extensionless URLs is required
IIS must be running in integrated mode; classic mode is not supported. Message delays of up to 30 seconds may be experienced if IIS is run in classic mode using the Server-Sent Events transport
The hosting application must be running in full trust mode
Note: If a client operating system is used, such as for development (Windows 8 or Windows 7), full versions of IIS or Cassini should not be used due to the built in limit of 10 simultaneous connections imposed This limit will be reached very quickly as connections are transient, frequently reestablished, and are not disposed of immediately when no longer being used. IIS Express should be used on client operating systems.
Note: For SignalR to use WebSocket, IIS 8 or IIS 8 Express must be used, the server must be using Windows 8, Windows Server 2012, or later, and WebSocket must be enabled in IIS. For information on how to enable WebSocket in IIS, see IIS 8.0 WebSocket Protocol Support.
SignalR can be used in a variety of web browsers, but typically, only the most recent two versions are supported.
Applications that use SignalR in browsers must use jQuery version 1.6.4 or major later versions (such as 1.7.2, 1.8.2, or 1.9.1).
SignalR can be used in the following browsers:
Microsoft Internet Explorer versions 8, 9, 10, and 11. Modern, Desktop, and Mobile versions are supported
Microsoft Edge
Mozilla Firefox: current version - 1, both Windows and Mac versions
Google Chrome: current version - 1, both Windows and Mac versions
Safari: current version - 1, both Mac and iOS versions
Opera: current version - 1, Windows only
Android browser
In addition to requiring certain browsers, the various transports that SignalR uses have requirements of their own. The following transports are supported under the following configurations:
Transport
*Internet
Explorer
Chrome
(Windows or iOS)
Firefox
Safari
(OSX or iOS)
Android
WebSockets
10+
current – 1
current - 1
current – 1
N/A
Server-Sent Events
N/A
current – 1
current - 1
current – 1
N/A
ForeverFrame
8+
N/A
N/A
N/A
4.1
Long Polling
8+
current – 1
current - 1
current – 1
4.1
*: 6+ required for full functionality.
While SignalR may run without major issues in older browser versions, we do not actively test SignalR in them and generally will not fix bugs that may appear in them.
StifleR uses the concept of 'Roaming Clients' and enables the ability to set bandwidth according to the client location and connectivity. A roaming client (in StifleR terms) is one that is not connected to the corporate network i.e. a known location/subnet or is non-domain joined and/or authenticated.
In these cases there are a couple of choices as to how these clients can be configured. These are determined by the StifleR Server setting DefaultRoamingBandwidth.
The default setting is 0 (disabled) which means that by default a StifleR client that roams will have all Bandwidth policies removed.
If, however, that parameter is set to anything other than zero Roaming policy will be applied (split between Delivery Optimization and BITS)
i.e. If a Default RoamingBandwidth of 50Mbs (51200) is set then the clients would get 25Mbs for BITS and 25Mbs for Delivery Optimization
There are two types of Roaming Client – Roaming and connected to a StifleR server: (possible if the client still has a route to the StifleR Server – via Azure for instance) and - Roaming but not connected to a StifleR server.
Well Connected locations are networks where the bandwidth available to clients is fairly generous (>100Mb/s). In this scenario StifleR can still assist with improving Peer-to-Peer and caching efficiencies, which help to offload both network and memory/CPU load from source servers (Distribution Points etc.)
How it Works:
Instead of setting a 'Target Bandwidth', you can set the location to 'WellConnected' and then set DO and BITS (BranchCache) Bandwidth limits. A Red Leader will still be selected, but the bandwidth allocated to 'Non-Red Leaders' is the same. This allows for faster P2P transfers and faster deployments in general.
The Default Setting is False - (Not Well Connected)
Note: You can change a subnet to Well Connected and the clients at that location will get the new Well-Connected bandwidth settings from the server. If you change back to Not Well Connected, the clients will not revert to the original Subnet Target Bandwidth until the next service restart.
