Tuesday 30 December 2014

Designing a Network for SaaS - Part 2

A whole range of factors have to be taken into account if you are planning to roll out a traditional server based network. In contrast the design objectives for a SaaS network are remarkably simple.
  • Resolve DNS as fast as possible. 
  • Get the data packet to the edge firewall as efficiently as possible.
Lets take each of these requirements in turn. Network design is covered in Part 3.

Resolving DNS.
In a SaaS network resolving DNS is particularly important since the majority of the resources are web based. SaaS services generate more DNS requests than legacy LAN based applications to the point where the user experience is heavily dependent on the speed of DNS requests. 

The standard deployment model requires at least two local DNS servers to resolve the addresses of internal resources. But in a basic SaaS deployment there are few (if any) internal resources that require DNS which brings into question the role of the internal DNS server. Without the requirement to resolve internal IP addressees it becomes advantageous use an externally hosted DNS server which is far more resilient and accessible than an internal service.

The problem of losing DNS if the internet connection is down is somewhat irrelevant if all the services that are referenced by DNS are external and accessed through the same connection. In reality the objection is mitigated by making the link resilient and by running a local DNS cache.

In the SaaS model the role of the internal DNS server is altered to act as a local cache for DNS requests.

The local DNS server should be configured as non-authoritative for any domain. As a caching-only server it does not contain any domain resource records. Instead, the server accepts DNS queries from client systems, resolves the name and caches the answer. This improves the responsiveness of the system by resolving DNS locally without passing requests out to an external server.

Client devices on the school site have DNS requests returned from the local cache while maintaining the ability to query the public DNS servers remotely.

If the school plans to implement a service such as Google Apps for Education (GAFE) the external forwarders should be the Google public DNS servers. Clients have the IP address of the local server as the primary DNS and the address of the Google server as the secondary DNS.

Google have produced a very useful Networking Guide that covers some of these concepts in more detail.

>>>>> Designing a Network for SaaS - Part 3

Friday 12 December 2014

Designing a Network for SaaS - Part 1

For the last decade network design has been based around a Windows workstation connected to a 1Gbs Ethernet port routing back to an on-premise server.

However the requirements for networks designed to support fixed position Windows clients and networks designed for mobile clients using SaaS are completely different.

In a traditional Windows network a significant proportion of the bandwidth is absorbed by supporting the OS and the networking environment and not the user experience. For example for any fixed period a proportion of the traffic will be utilised with user profile transfers, Window updates, Kerberos authentication, NetBIOS network neighborhood traffic, Active Directory and DFS replication, GPO management and general application level broadcasting activity. Bandwidth is also absorbed by anti-virus software, data archiving and other management utilities.

The type of workflow adds to the problem. The lack of any collaborative space outside of a product such as MS SharePoint means that files are replicated between users or emailed to each other ending up in local files which have to be constantly synced.

None of this overhead applies to a SaaS network and as a consequence same amount of bandwidth can be used to support many more users. As the number increases the ability of the network to response quickly to requests (latency) is not reduced by background broadcast traffic because clients on a SaaS network don't broadcast (much).

   On the internet nobody can hear you broadcast ! …..with apologies to Alien ©.    

How can you design a network to take advantage of these features?

Network traffic is automatically limited since there is almost no peer-peer data movement and SaaS traffic can’t exceed bandwidth of the internet connection.

Therefore any investment in local high end infrastructure such as 10Gbs Ethernet is largely pointless. A SaaS network has no activity that can make use of the extra capacity. In the same way there is little advantage to to gained running data over higher specified cabling such as CAT6 as opposed to CAT5e unless there is also a distance requirement.

The value of managing network traffic using a multiple VLANS is also worth reexamining. In a traditional network VLANS fulfill a number of roles some of which don't apply or have reduced importance on a smaller SaaS network. In a fixed cable network limiting the size of collision domains is taken care of by Layer 2 switching leaving the VLANs to partition broadcast traffic.  In the future the end user device will be connected wirelessly and the efficiency of the network will be impacted by the available frequency channels far more than fixed wired collision domains. Also a SaaS network has almost no broadcast traffic so the requirement to partition broadcast traffic is also far less important.

The requirement of VLANS to segment network traffic for security reasons is also very limited. There are no no-premise servers and therefore far fewer console ports or administration functions that need protecting.

In some of the more advanced wireless network technologies some of the functions of a VLAN have been transferred to policies applied to the SSID’s. The guest wireless network is the obvious example. This is protected by an security policy applied on each Wireless Access Point (WAP) which restricts traffic to a single IP address - the external gateway. If the network has a console port that need protecting from casual access (examples would be the UPS, on-site appliance and possibly catering and security equipment) this can be achieved by creating an exception list for the specific SSID rather than supporting a routed VLAN structure on the switches.

The schools running a Voice Over IP (VoIP) system the requirement to apply policies to protect voice data from being delayed by background traffic (QoS) is a standard feature of most traditional networks. However a network design which is very flat and and concentrates all traffic into a high performance core with very little broadcast chatter is unlikely to need QoS to maintain acceptable voice quality on a 1Gb LAN.

In summary a complex VLAN structure could be reduced to two VLANs - Management (Default VLAN1) which contains the switches and AP’s and Data (VLAN10) which has everything else. Policies are applied though the SSID’s attaching to VLAN.

This massively simplifies switch port management for the school. The network would need 1Gbs Ethernet but only to support wireless AP’s. If the majority of the devices are wireless the limiting factor for network bandwidth will be accesss to an open wireless frequency. The number of wireless clients is irrelevant.

>>>>> Designing a Network for SaaS - Part 2