Chapter 4

Services

Slide #1
 Topics
1. Service Requirements
2. Open Architecture
3. Service Design Principles

Slide #2
 Servers vs Services
A server is a piece of hardware.

A service is the function that is provided by

Slide #3
 Services
• Distinguish structured computing environment
from some standalone PCs.
• Large orgs linked through shared services to ease
communication and optimize resources.
• Typical environments have many services
– Fundamental: net, DNS, email, auth, printing.
– Typical: DHCP, backup, directory, file, license.
• Services often depend on other services
– Almost everything depends on DNS.

Slide #4
 Providing a Service
A service is more than hardware + software.

A service must be
1. Reliable.
2. Scalable.
3. Monitored.
4. Maintained.
5. Supported.

Slide #5
 Servers and Services
For a service to be reliable, servers should:
– Be as simple as possible.
– Have minimum software to run service.
– Depend on as few other services as possible.
– Depend only on services that are at least as
reliable as the service running on the server.
– Have access restricted to SAs.
– Be as few as needed for performance +
reliability.

Slide #6
 Customer Requirements
Customers are the reason for the service.
– How do they intend to use it?
– What features do they need?
– What features would they like to have?
– How critical is the service?
– What levels of availability and support are needed?
Service Level Agreement (SLA)
– Enumerates services.
– Defines level of support.
– Commits to response times for problem types.

Slide #7
 Operational Requirements
Essential to designing a reliable service
– What services does it depend upon?
– What other services will depend upon it?
– How does it interoperate with other services?
– How can it be integrated with auth/dir services?
– How does the service scale?
– How can the service be upgraded?
• Downtime requirements.
• What systems are affected?

Slide #8
 Open Architecture
Service should be built around open standards
– Check IETF RFCs to see if it’s an open protocol.
– Example service: SMTP
– Example products: exim, postfix, qmail, sendmail.
– Open standards don’t require open source.
Allows vendors to make interoperable products.
– Avoids vendor lock-in.
– Allows vendor competition (cheaper prices for you.)
– Decouples client selection from server selection.
– Avoids need for protocol gateways.

Slide #9
 Requests for Comments (RFCs)
Documentation for Internet protocols,
technologies, and methodologies.
– Standards track RFCs describe Internet standards
(TCP, IP, SMTP) and must be approved by IETF.
– Experimental RFCs may become standards.
– Best Common Practice RFCs describe how to run
services or use protocols.
– Informational RFCs is a catch-all including
proprietary protocols, April Fool’s jokes, etc.
Available from http://www.rfc-editor.org/
Slide #10
Principles for Designing a Reliable Service

Simplicity
– The more features, the more bugs.
– Simplicity increases reliability, ease of
maintenance.
Vendor Relations
– Can be helpful about configuring service.
– Let vendors compete for your business.
– Stick to vendors who develop for your platform.

Slide #11
 Machine Independence
Will eventually move service to new host.
– Want to avoid having a downtime.
– Want to avoid reconfiguring every desktop.
Use generic DNS alias for machine
– Mail server has name romero
– DNS alias is smtp
Use virtual IP addresses for non-name svcs
– Machine has usual IP address: 192.168.1.54
– Virtual: ifconfig eth0:0 192.168.1.5

Slide #12
 Dedicated Machines
Put each service on its own machine(s).
– If a server crashes, only impacts one service.
– Easier to debug if only one service running.
– Performance tuning easier with one service.
– If you can’t afford a new machine, use a VM.

Slide #13
 Environment
Safe environment
– Improves reliability: AC, UPS, physical security.
– Data center usually provides faster network too.
– Only rely on services provided by data center.
Restricted access
– Customers should not need to login to servers.
– More logins decrease stability, performance.
– Even Windows can be stable w/o user logins.

Slide #14
 Principles for Designing a Reliable Service

Service components should be tightly coupled.

Slide #15
 Performance
Latency vs throughput
– Latency is delay before data received.
– Throughput is how much data sent per second.
– Performance problems typically affects one.
– Increasing the other will not solve your problem.
Remote sites
– May have high latency to main site.
– Do you need secondary servers at remote sites?

Slide #16
 Capacity Planning
Estimate capacity from testing.
– Test server at 100 qps, 200 qps, until slow.
– Identify resources used by each query
• RAM
• Disk
• Network
• CPU
Can service be split onto multiple servers?
– Can it be done w/o users noticing?

Slide #17
Principles for Designing a Reliable Service
Monitoring
– Availability, problems, performance.
– Auto-alert front line support.
– Customers shouldn’t discover problems before SA.
– Capacity planning: CPU, mem, disk, network, licenses.
Service Rollout
– First impressions are difficult to change.
– Be ready for support: docs, trained helpdesk.
– Use one, some, many technique.

Slide #18
 Key Points
Servers vs desktops
– Requirements and hardware differences.
Redundancy
– Full vs n+k redundancy.
– Hot plug vs hot spare.
Services
– Requirements: service, server, customer, op.
– Machine independence and open architectures.
Performance
– Latency vs. throughput.

Slide #19