Internet Information server (IIS) 8 is available to the public for
testing and even production workload testing. Many system
administrators have been anxious to kick the tires and to find out which
features are coming.
I’ll include a high level overview of what
we will see in the upcoming version of IIS. The focus with this
release of IIS 8 is on the large scale hoster. There are substantial
performance improvements to handle thousands of sites on a single server
farm—with ease. Everything that I mention below is available for
download and usage today.
Forgive
me if there are typos. I’m writing this while at the MVP Summit in
Seattle while trying to listen to another session at the same time.
Thanks to the IIS team who gave detailed demos on this yesterday and
gave me permission to talk about this.
Real CPU Throttling
Previous
versions of IIS have CPU throttling but it doesn’t do what most of us
want. When a site reaches the CPU threshold the site is turned off for a
period of time before it is allowed to run again. This protects the
other sites on the server but it isn’t a welcome action for the site in
question since the site breaks rather than just slowing down.
Finally
in version IIS 8 there are kernel level changes to support real CPU
Throttling. Now there are two new actions for sites that reach the CPU
threshold. They are
Throttle and
Throttle under load. If you used
WSRM to achieve this in the past, you no longer need to do so, and the functionality is improved over what is available with WSRM.
The
throttle
feature will keep the CPU for a particular worker process at the level
specified. Throttling isn’t applied to just the primary worker process,
but it also includes all child processes, if they happen to exist.
The
Throttle under load
feature will allow a site to use all possible CPU if it’s available
while throttling the worker process if the server is under load.
The
throttling is based on the user and not specifically on the application
pool. This means that if you use dedicated users on more than one app
pool then it throttles for all of app pools sharing the same user
identity. Note that the application pool identity user is unique so if
you use the app pool identity user—which is common—then each app pool
will be throttled individually.
This is a welcome new feature and is nicely implemented.
SSL Scalability
Unless
you deal with large scale site hosting with many SSL certificates you
may not have realized that there is room for improvement in this area.
Previous
versions of IIS have limited secure site density. Each SSL site
requires its own IP address and after adding a few SSL sites, startup
performance becomes slow and the memory demand is high. Every
certificate is loaded into memory on the first visit to an SSL site
which creates a large memory footprint and a long delay on the first
load.
In IIS 8 the SSL certificate count is easily scalable to
thousands of secure sites per machine with almost instantaneous
first-loads. Only the certificate that is needed is loaded and it will
unload after a configurable idle period. Additionally, enumerating or
loading huge numbers of certificates is substantially improved.
SNI / SSL Host Header Support
Using host headers and a shared IP address with SSL certificate has always been problematic.
IIS 8 now offers Server Name Indication (SNI) support which allows many
SSL sites to share the same IP. SNI is a fairly new feature (within
the last few years) which allows host headers to work with SSL. It
does this by carrying the target host name in the TLS handshake rather
than the encrypted part of the packet.
IIS 8 makes SNI support a first class citizen in the site bindings.
Note
that SNI doesn't work on all browsers. For example, Internet
Explorer in Windows XP does not support SNI. Read more about that from
Eric Law's
blog post.
Over 85% of browsers is use today support SNI, but since it's not 100%,
it will not work universally. However, like the adoption issue with
host headers in the '90s, it will a fully supported before we know it.
More details with a list of browsers can be found here:
http://en.wikipedia.org/wiki/Server_Name_Indication
This
sets the stage for sharing IP addresses which is extra important as
ipv4 IPs become more valuable and consolidation of IPs becomes the
trend.
SSL Manageability - Central Certificate Store (CCS)
In
IIS 7 managing SSL is labor intensive, particularly for server farms.
All certificate must be imported on every machine in the farm. When
setting up new servers you must account for time needed to import
certificates when scaling out, and even on small server farms. In
previous versions keeping certificates in sync between servers is
difficult to manage and often requires manual steps.
In IIS8
there is a new Central Certificate Store (CCS). Central Certificate
Store allows storing certificates on a central file share instead of
each machine. You can point the servers to a single network share, or
use replication like DFS-R to sync the folders between machines.
Renewal
and syncing is as simple as xcopying pfx files to the location that you
specify when enabling CCS on the web server. Enabling CCS is straight
forward too. It works very similar to enabling Shared Configuration.
CCS compliments the SNI functionality to support sites with multiple certs and a single IP.
The
mapping of bindings to certificates uses a bit of magic … by convention
rather than configuration. This is important for extremely large lists
of certificates. Now you don't need to select them from a huge list. The
value of the host header needs to match the name of the cert. Your CCS
folder will have many .pfx files with names that match the domain name.
Basically the name of the .pfx files in the certificate store is the
primary key.
If you use a wildcard cert then it needs to be named _.domain.com.pfx.
As
you would assume, there is support for Multiple Domain Certificates
(Unified Communications Certificate [UCC]). If you use multiple domain
certificates using the subjectAltName feature of the certificate then
you just create multiple copies of the pfx, one for each subjectAltName.
Note that you can use the old method which binds to by certificate identifier and it works the same as it did in the past.
Furthermore
there is a neat feature for the central repository that allows grouping
by expiration date, which groups by "Today / This Week / Next Week /
Next Month / Later" which is handy for seeing which certificates are
ready to expire.
With these changes to the certificates, it makes for a powerful solution for large scale webfarm hosting with multiple tenants.
Dynamic IP Restrictions
Information about this is already available on the web, but it's moving along and getting closer for the final release.
FTP Logon Restriction
Yay.
A new FTP IP Restrictions module is coming! This is similar in concept
to Dynamic IP Restrictions for HTTP. One of the key differences is that
it does gray listing rather than black listing. When someone is blocked,
they are only blocked for the sample period (e.g. 30 seconds). This is
nice because it's enough to thwart or slow brute force and common name
password attacks, but legit invalid attempts can continue to attempt to
log in without waiting for long periods of time.
What's extra
nice about having this feature is that you can set it slightly more
sensitive than your domain username lockout policy so that brute force
attacks don't cause your username to be locked out from too many invalid
attempts. The FTP IP Restrictions can throttle the hack attempts
without locking out your domain users.
Application Initialization Module
Previously
known as the application warm-up module which was pulled for a time,
now it's ready in full force as Application Initialization Module.
This
allows spinning up sites and pages before traffic arrives and handling
of requests in a friendly way while the application first loads. It's
not uncommon for a site to take a minute or longer on the first load
(yes SharePoint admins, we feel your pain). This allows you to protect
the end user from being the person that triggers this.
It's
possible to set a warm-up page at the server level as a single setting,
or you can use powerful URL Rewrite rules for more flexibility.
You
can also ensure that your load balancer’s health test page doesn’t
serve up a valid response until the site is fully initialized according
to your preferences. Then the load balancer will bring a node into
rotation only after the entire warm-up has completed.
Configuration Scale
The
IIS configuration files (e.g. applicationHost.config) can handle very
large files with ease now. There are substantial performance
improvements in the upcoming version. Only administrators with large
numbers of sites on the same server or server farm (think thousands)
would have noticed before, but for large scale performance the new
changes are paving the way for huge scale.
Web Sockets
It’s
important to include Web Sockets in this list too. Apart from some
brief information I really haven’t looked into Web Sockets in detail yet
so I’ll just
include a great link from Paul Batum on it. Web Sockets does require Windows 8 or later on the server side.
All
in all these are welcome changes. While previous versions of IIS
already did a great job of handling massive amounts of traffic, IIS 8
now can handle thousands (or tens of thousands) of sites and their
extensive configurations on a single server farm. With HTTP and FTP
logon restrictions, CPU throttling, the Application Initialization
Module, and large scale SSL and configuration improvements, IIS 8 brings
a number of welcome improvements.