Your SlideShare is downloading. ×
0
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

System

201

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
201
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. System &amp; Network Administration <ul><li>Chapter 3 – Service </li></ul><ul><li>By Chang-Sheng Chen (200803011) </li></ul>
  • 2. Contents of Chapter 3 <ul><li>3.1 The Basics </li></ul><ul><ul><li>3.1.1 Customer Requirements </li></ul></ul><ul><ul><li>3.1.2 Operational Requirements </li></ul></ul><ul><ul><li>3.1.3 Open Architecture </li></ul></ul><ul><ul><li>3.1.4 Simplicity </li></ul></ul><ul><ul><li>3.1.5 Vendor Relation </li></ul></ul><ul><ul><li>3.1.6 Machine Independence </li></ul></ul><ul><ul><li>3.1.7 Environment </li></ul></ul><ul><ul><li>3.1.8 Restricted Access </li></ul></ul><ul><ul><li>3.1.9 Reliability </li></ul></ul><ul><ul><li>3.1.10 Single or Multiple Servers </li></ul></ul><ul><ul><li>3.1.11 Centralization and Standards </li></ul></ul><ul><ul><li>3.1.12 Performance </li></ul></ul><ul><ul><li>3.1.13 Monitoring </li></ul></ul><ul><ul><li>3.1.14 Service Rollout </li></ul></ul><ul><li>3.2 The Icing </li></ul><ul><ul><li>3.2.1 Dedicated Machine </li></ul></ul><ul><ul><li>3.2.2 Full Redundancy </li></ul></ul><ul><li>3.3 Conclusion </li></ul>
  • 3. The Basics <ul><li>The most important thing to consider at all stages of design and deployment is the customers’ requirements . </li></ul><ul><ul><li>Talk to the customers and find out what their needs and expectations are for the services. </li></ul></ul><ul><li>Then, build a list of other requirements that are only visible to the SA team . </li></ul><ul><ul><li>Focus on what , rather than how . </li></ul></ul><ul><li>Service should be built on server-class machines that are kept in a suitable environment. </li></ul>
  • 4. The Basics (cont.) <ul><li>Access to server machines should be restricted to SAs for reasons of reliability and security. </li></ul><ul><li>An SA has several decisions to make when building a service. </li></ul><ul><ul><li>Choosing vendors and products ( software, hardware) </li></ul></ul><ul><ul><li>Reliability, performance, etc. </li></ul></ul>
  • 5. The Basics (cont.) <ul><li>Most services rely on other services . </li></ul><ul><ul><li>Understanding in detail how a service works will give you insight into the service on which it relies. </li></ul></ul><ul><ul><ul><li>For example, almost every service relies on name service (DNS). DNS relies on network , and therefore, anything that relies on DNS also relies on network. </li></ul></ul></ul><ul><li>A service should be built as simple as possible , with as few dependencies as possible , to increase reliability and make it easier to support and maintain. </li></ul>
  • 6. The Basics (cont.) <ul><li>Another method of easing support and maintenance is to use standard hardware/software , standard configurations and have documentation in a standard location . </li></ul><ul><li>A key part of implementing any new service is to make it independent of the particular machine </li></ul>
  • 7. 3.1.1 Customer Requirements <ul><li>When building a new service, you should always start with the customer requirements. </li></ul><ul><li>Gathering the customer requirements </li></ul><ul><ul><li>There are very few services that do not have customer requirements. </li></ul></ul><ul><ul><ul><li>DNS, authentication services , etc. </li></ul></ul></ul><ul><li>A Service Level Agreement (SLA) </li></ul><ul><ul><li>An SLA enumerate the services that will be provided and the level of support they receive . </li></ul></ul>
  • 8. Service Level Agreement (cont.) <ul><li>A Service Level Agreement (SLA) </li></ul><ul><ul><li>An SLA enumerate the services that will be provided and the level of support they receive . </li></ul></ul><ul><ul><li>It typically categories problems by severity and commits to response times for each category. </li></ul></ul><ul><ul><li>The SLA usually defines an escalation process that increases the severity of a problem if it has not been resolved after a specified time and calls for managers to get involved if problems are getting out of hand. </li></ul></ul>
  • 9. Service Level Agreement (SLA) <ul><li>The SLA process is a forum for the SAs to understand the customers’ expectations and to set them appropriately, so that the customers can understand what is and is NOT possible and why . </li></ul><ul><ul><li>It is a tool to plan what resources will be required. </li></ul></ul><ul><ul><li>The SLA should document the customers’ requirements and set realistic goals for the SA teams in terms of features , availability, performance, and support. </li></ul></ul><ul><ul><li>It should document future needs and capacity so that all parties will understand the growth plans. </li></ul></ul>
  • 10. 3.1.2 Operation Requirements <ul><li>The SA team may have other requirements for the new service that are not immediately visible to the customers. </li></ul><ul><ul><li>The administrative interface , whether it interoperates with other existing services and can be integrated with central service such as authentication or directory services. </li></ul></ul><ul><ul><li>SAs also need to consider how the service scales. </li></ul></ul><ul><ul><li>A related consideration is the upgrade path for the service </li></ul></ul><ul><ul><li>The level of reliability </li></ul></ul><ul><ul><li>Network performance issues </li></ul></ul><ul><ul><li>Monitoring issues ( availability, performance, etc.) </li></ul></ul><ul><ul><li>Budget issues </li></ul></ul>
  • 11. Operation Requirements (cont.) <ul><li>Questions about an upgrade process: </li></ul><ul><ul><li>Does it involve an interruption of service ? </li></ul></ul><ul><ul><li>Does it involve touching every desktop ? </li></ul></ul><ul><ul><li>Is it possible to rollout the upgrade slowly, to test it on a few willing people before inflicting it on whole organization ? </li></ul></ul><ul><li>Try to design the service, so that upgrades are easy, can be performed without service interruption, don’t require touching the desktops, and can be rolled out slowly. </li></ul>
  • 12. 3.1.3 Open architecture <ul><li>Whenever possible , a new service should be built around open protocols and file formats. </li></ul><ul><ul><li>Any service with an open architecture can be more easily integrated with other services that follow the same standards. </li></ul></ul><ul><li>The business case for using open protocols is simple: </li></ul><ul><ul><li>it lets you build better services because you can select from the best server and client , rather than being forced to pick, for example, the best client and then getting stuck with a less than optimal server. </li></ul></ul>
  • 13. Open architecture (cont.) - The ability to decouple the client and server selections <ul><li>A better way to select protocols based on open standards ad permit each side (i.e., client and server) to select their own software. </li></ul><ul><ul><li>Customers are free to choose the software that best fits their own needs, biases, and even platforms. </li></ul></ul><ul><ul><li>SAs can independently choose a server solution based on their needs for reliability, scalability, and manageability. </li></ul></ul><ul><ul><ul><li>The SAs can now choose between competing server products, rather than being locked into the (potential difficult to manage) server software and platform required for a particular client application. </li></ul></ul></ul><ul><ul><li>Open protocols provide a level playing field that inspire competition between vendors, which benefits you. </li></ul></ul>
  • 14. Open architecture (cont.) <ul><li>Open protocols and file formats are typical quite static (or only change in upward compatible ways) and widely support, </li></ul><ul><ul><li>giving you the maximum product choice and maximum chance of reliable, interoperable products. </li></ul></ul><ul><li>The other benefit of using open systems is that you don’t require a gateway to the rest of world. </li></ul><ul><ul><li>Gateways are additional services that require capacity planning, engineering, monitoring, and everything else mentioned in this chapter </li></ul></ul><ul><li>Case Study </li></ul><ul><ul><li>Hazards of Proprietary Email Software </li></ul></ul><ul><ul><ul><li>Primarily based on client user interface and features (e.g., Graphic User Interface, etc.) and no concerns for server management, reliability and scalability </li></ul></ul></ul><ul><ul><ul><ul><li>All messages from all users in a single large file </li></ul></ul></ul></ul><ul><ul><li>Protocol Gateway Reduce Reliability </li></ul></ul><ul><ul><ul><li>Microsoft Exchange Server </li></ul></ul></ul>
  • 15. 3.1.4 Simplicity <ul><li>When architecting a new service, simplicity should be your foremost consideration. </li></ul><ul><ul><li>The simplest solution that satisfying all the requirements will be the most reliable , easiest to maintain , easiest to expand , and easiest to integrate with other systems . </li></ul></ul><ul><ul><li>As the system grows, it will become complex. Therefore, starting out as simple as possible delays the day when a system has become too complex. </li></ul></ul><ul><li>Sometimes, one or two requirements from the customer or SAs may add considerably to the complexity of the system. </li></ul><ul><ul><li>Reevaluate the importance of these requirements </li></ul></ul><ul><ul><ul><li>These requirements could be met, but at a cost to reliability, support levels, and on-going maintenance. </li></ul></ul></ul>
  • 16. 3.1.5 Vendor Relations <ul><li>When choosing hardware and software for a service, you should be able to talk to sale engineers from your vendors to get advices on the best configuration from your application . </li></ul><ul><ul><li>Hardware vendors sometimes have product configurations that are tuned for particular applications, such as database or web server. </li></ul></ul><ul><li>If there is more than one server vendor in your environment, and it seems that more than one of your vendors has an appropriate product , You should use the situation to your advantage . </li></ul><ul><ul><li>Get those vendors biding against each other </li></ul></ul><ul><ul><ul><li>the same price for more performance, reliability, or scalability </li></ul></ul></ul><ul><ul><ul><li>Get a better price and be able to invest the surplus </li></ul></ul></ul><ul><ul><li>Even if you know which vendor you will choose, don’t let them know that you have decided until you are convinced that you have the best deal possible . </li></ul></ul>
  • 17. 3.1.5 Vendor Relations (cont.) <ul><li>When choosing a vendor, particularly for software product , it is important for you to understand the direction in which the vendor is taking the product. </li></ul><ul><ul><li>For key, central service , such as authentication or directory services, it is essential to stay in touch with the product direction , or you may suddenly discover that the vendor no longer supports your platform. </li></ul></ul><ul><li>If possible, try to stick to vendors who develop the product primarily on the platform you use , rather than port it to other platform. </li></ul><ul><ul><li>Having fewer bugs, receiving new features first, and better support, etc. </li></ul></ul>
  • 18. 3.1.6 Machine Independence <ul><li>For Name-based Service (Ch.6 Name Service) </li></ul><ul><li>Clients should always access a service using a generic name that is based on the function of the service. </li></ul><ul><ul><li>E.g., Smtp.nctu.edu.tw, pop3.nctu.edu.tw </li></ul></ul><ul><li>The machine should never have a primary machine name that is functional-based, </li></ul><ul><ul><li>because ultimately the function may need to move to another machine. For example, </li></ul></ul><ul><ul><ul><li>Primary name : DcMg.nctu.edu.tw </li></ul></ul></ul><ul><ul><ul><li>Alias (service) name : smtp.cc.nctu.edu.tw </li></ul></ul></ul>
  • 19. 3.1.6 Machine Independence (cont) <ul><li>For IP address based services , </li></ul><ul><li>we could also use some techniques (such as layer 4 switching) to give the machine that the service runs on multiple virtual IP addresses in addition to the primary real IP address. </li></ul><ul><ul><li>Then the virtual address and the service can be moved to another machine relatively easily. </li></ul></ul>
  • 20. 3.1.7 Environment <ul><li>A fundamental piece of building a service is providing a reasonable high level of availability , which means placing all the equipments associated with that service into a data center (cf. Ch.17). </li></ul><ul><ul><li>A data center provides protected power, plenty of cooling, controlled humidity (vital in dry or damp climates), fire suppression, and a secure location where the machine should be free from accidental damage or disconnection. </li></ul></ul><ul><ul><li>In addition, a server often needs much high speed network connections (e.g., high-speed links, more interfaces) than its clients because it needs to be able to communicate at reasonable speeds with many clients simultaneously. </li></ul></ul><ul><ul><ul><li>High-speed network cabling and hardware typically are expensive to deploy </li></ul></ul></ul>
  • 21. Environment (cont.) <ul><li>None of the components of the service should rely on anything than runs on a machine that is not located in the data center. </li></ul><ul><ul><li>The service is only as reliable as the weakest link in the chain of the components that need to be working for the service to be available. </li></ul></ul><ul><ul><li>If that is the case, find a way to change the situation: </li></ul></ul><ul><ul><ul><li>Move the machine into a data center </li></ul></ul></ul><ul><ul><ul><li>Replicate that service onto a data center machine </li></ul></ul></ul><ul><ul><ul><li>Remove the dependency on the less reliable machine </li></ul></ul></ul><ul><li>Case Study </li></ul><ul><ul><li>Hazards of servers relying on Non-servers </li></ul></ul><ul><ul><ul><li>NFS automount </li></ul></ul></ul>
  • 22. 3.1.8 Restricted Access <ul><li>Restricting server access to the SA team from the beginning is the best approach to ensure reliability and expected performance levels . </li></ul><ul><ul><li>There should be no reason for anyone to log in to a server other than an SA performing administrative work on the server. </li></ul></ul><ul><ul><ul><li>The fewer people who log in to a machine, the more stable it is. </li></ul></ul></ul><ul><ul><li>If a customer can and becomes accustomed to logging in to a particular server, he probably will start running other jobs on it that take CPU and I/O cycles away from the services , without realizing that he is adversely affecting the service . </li></ul></ul><ul><ul><ul><li>E.g., NFS server </li></ul></ul></ul>
  • 23. 3.1.9 Reliability <ul><li>If you have redundant hardware available, use it as effectively as you can. </li></ul><ul><li>The single most effective way to make a service as reliable as possible is to make it as simple as possible. </li></ul><ul><ul><li>Find the simplest solution that meets all the requirements. </li></ul></ul><ul><li>When you are building a service at a central location that will be accessed from remote sites, it is particularly important to take network topology into account. </li></ul><ul><ul><li>If connectivity to the main site is down, can the service still be available to remote sites ? </li></ul></ul><ul><ul><ul><li>Some, Yes  stale name service, authentication service </li></ul></ul></ul><ul><ul><ul><li>Others, No,  database or file service </li></ul></ul></ul>
  • 24. 3.1.10 Single or Multiple Servers <ul><li>Independent services (or daemons) should always be on separate machines , if cost and staffing-levels permitting . </li></ul><ul><ul><li>However, if the service that you are building is actually composed of more than one new application or daemon and the communication between those components is over a network, you need to consider whether to put all of the components on one machine or to split them across many machines . </li></ul></ul><ul><ul><ul><li>E.g., a website with a database , a mail system with many filtering mechanisms (e.g., anti-spam, anti-virus, etc.) </li></ul></ul></ul><ul><ul><li>The choice may be determined by security, performance, or scaling concerns . </li></ul></ul>
  • 25. Single or Multiple Servers (cont.) <ul><li>In other cases, one of the components will initially only be used for this one application , but may later be used by other applications. E.g., </li></ul><ul><ul><li>calendar service + LDAP server (Initially) </li></ul></ul><ul><ul><li>Mail service + LDAP server (later) </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>If a service, such as LDAP, may be used by other services in the future , it should be placed on dedicated machines, </li></ul><ul><ul><li>so that the calendar service can be upgraded and patched independently of the (ultimately more critical) LDAP servers. </li></ul></ul>
  • 26. Single or Multiple Servers (cont.) <ul><li>Sometimes, two applications or daemons may be completely tied together and will never be used apart from each other. </li></ul><ul><ul><li>In this situation, it makes sense to put them both on the same machine. </li></ul></ul><ul><ul><li>E.g., mail server + DNS caching server </li></ul></ul><ul><li>Video Streaming Server </li></ul><ul><ul><li>Encoding, Streaming Server </li></ul></ul>
  • 27. 3.1.11 Centralization and Standards <ul><li>An element of building a service is centralizing the tools, applications, and services that your customers’ need. </li></ul><ul><ul><li>Centralization ( 集中化 / 單一窗口 ) means that the tools, applications, and services are primarily managed by one central group of SAs on a single central set of servers . </li></ul></ul><ul><ul><li>Support for these services is provided by a central helpdesk . </li></ul></ul><ul><li>Centralizing services and building them in standard ways make them easier to support and lower training costs . </li></ul><ul><ul><li>The service should be designed and documented in some consistent way , so that the SA answering the support call knows where to find everything and thus can respond more quickly . </li></ul></ul>
  • 28. Centralization and Standards (cont.) <ul><li>Centralization does not preclude centralizing on regional or organization boundaries , particularly if each region or organization has its own support staff. </li></ul><ul><ul><li>Some services , such as e-mail, authentication services and networks, are part of the infrastructure and need to be centralized . </li></ul></ul><ul><ul><ul><li>For large sites, these services can be built with a central core that feeds information to and from distributed regional and organizational systems. </li></ul></ul></ul><ul><ul><li>Other services , such as file services and CPU farms, are more naturally centralized around departmental boundaries . </li></ul></ul>
  • 29. 3.1.12 Performance <ul><li>From a customer’s view , two things are important in any service: </li></ul><ul><ul><li>“ Does it work ?” and “ Is it fast ?” </li></ul></ul><ul><li>When designing a service , you need to pay attention to its performance characteristics , </li></ul><ul><ul><li>even though there may be many other difficult technical challenges to overcome. </li></ul></ul><ul><li>Performance expectations increase constantly as networks, graphics, and processors get faster. </li></ul><ul><ul><li>To build a service that performs well , you need to understand how it works and perhaps look at ways of splitting it effectively across multiple machines . </li></ul></ul>
  • 30. 3.1.12 Performance (cont.) <ul><li>Performance expectations increase constantly as networks, graphics, and processors get faster. </li></ul><ul><ul><li>Performance that is acceptable now , may not be six months or a year from now. </li></ul></ul><ul><li>To build a service that performs well , you need to understand how it works and perhaps look at ways of splitting it effectively across multiple machines. </li></ul><ul><ul><li>You also needs to consider how to scale the performance of the system as usage and expectation rise above what the initial system can do. </li></ul></ul>
  • 31. 3.1.12 Performance (cont.) <ul><li>When choosing the servers that run the service, consider how the service works . </li></ul><ul><ul><li>A lot of disk I/O ? </li></ul></ul><ul><ul><ul><li>More disk read than write (or vice versa) </li></ul></ul></ul><ul><ul><li>Keeping large tables of data in main memory ? </li></ul></ul><ul><ul><ul><li>Lots of fast memory and larger memory caches </li></ul></ul></ul><ul><ul><li>A network-based service that sends large amount of data to clients or between servers ? </li></ul></ul><ul><ul><ul><li>Multiple dedicated servers with high-speed interfaces, clusters of servers, etc. </li></ul></ul></ul>
  • 32. Performance (cont.) <ul><li>Case Study </li></ul><ul><ul><li>Bad capacity planning makes a bad first impression </li></ul></ul><ul><ul><li>Performance at remote sites (i.e., over wide area links ) </li></ul></ul><ul><ul><ul><li>Web site (e.g., different content for Modem, T1, High speed links, etc.) </li></ul></ul></ul><ul><ul><ul><ul><li>Solution: Proxy server (HTTP accelerator ) </li></ul></ul></ul></ul><ul><ul><ul><li>Handset windows vs. computer windows </li></ul></ul></ul>
  • 33. Performance at remote sites <ul><li>Performance of the service for remote sites may also be an issue. </li></ul><ul><ul><li>In some cases , quality of service or intelligent queuing mechanisms can be sufficient to make performance acceptable. </li></ul></ul><ul><ul><ul><li>E.g., mail relays/forwarders, web proxies, etc. </li></ul></ul></ul><ul><ul><li>In others , you may need to look at ways for reducing the network traffic . </li></ul></ul><ul><ul><ul><li>Different content on a web system for different speed of links (e.g., text-only versions for low-speed links (modem, T1) and graphical versions for high-speed links, etc.) </li></ul></ul></ul>
  • 34. 3.1.13 Monitoring (Ch.24) <ul><li>A service is not complete and cannot be called a service unless it is being monitored for availability, problems, and performance and there are capacity planning mechanisms in place. </li></ul><ul><ul><li>The helpdesk , or front-line support group, must be automatically alerted to problems with the service so that they can start fixing them before too many people are affected by these problems. </li></ul></ul><ul><ul><li>Likewise, the SA group should monitor the service on an ongoing basis from a capacity planning standpoint. </li></ul></ul><ul><ul><ul><li>E.g., network bandwidth, server performance, transaction rates, license and physical device availability, etc. </li></ul></ul></ul>
  • 35. Monitoring Example - Statistics for mail.nctu.edu.tw
  • 36. Monitoring Example (cont.)
  • 37. Monitoring Example (cont.)
  • 38. Monitoring Example (cont.)
  • 39. 3.1.14 Service Rollout ( 首次推出 ) <ul><li>Make sure the customers’ first impression are positive. </li></ul><ul><ul><li>The rollou t and the customers’ first experiences with the service will color the way that they view the service in the future. </li></ul></ul><ul><li>One of the key pieces of making a good impression is having all of the documentation available , the helpdesk familiar with and trained on the new service , and all the support procedures in place. </li></ul><ul><ul><li>There is nothing worse than having a problem with a new application and finding out that no one seems to know anything about it when you look for help. </li></ul></ul>
  • 40. 3.1.14 Service Rollout (cont.) <ul><li>The rollout also includes building and testing a mechanism to install new software and configuration settings that are needed on each desktop. </li></ul><ul><ul><li>One-some-many technique </li></ul></ul><ul><ul><ul><li>One  Some  Many </li></ul></ul></ul><ul><li>Ideally, no new desktop software or configuration should be required for the service , because that is less disruptive for your customers and reduce maintenance, </li></ul><ul><ul><li>but installing new client software on the desktops is frequently. </li></ul></ul><ul><ul><li>E.g., enabling IEEE 802.1x authentication scheme, web browser (IE vs. Firefox) </li></ul></ul><ul><li>New Trend </li></ul><ul><ul><li>Example: SSL VPN vs. PPTP VPN </li></ul></ul>
  • 41. 3.2 The Icing <ul><li>3.2.1 Dedicated Machine </li></ul><ul><li>3.2.2 Full Redundancy </li></ul><ul><ul><li>E.g., Name Service &amp; Authentication Services </li></ul></ul><ul><ul><li>Primary vs. Secondary (duplicate) set of servers </li></ul></ul><ul><ul><ul><li>Failed-over, backup </li></ul></ul></ul><ul><ul><li>Tightly coupled vs. loosely-coupled servers </li></ul></ul><ul><ul><ul><li>Load-sharing, performance-increasing </li></ul></ul></ul>
  • 42. 3.2.1 Dedicated Machine <ul><li>Having dedicated machines for each service </li></ul><ul><ul><li>More reliable </li></ul></ul><ul><ul><li>Debugging easier when there are reliability problem </li></ul></ul><ul><ul><li>Outage ( 暫時中斷服務 ) more limited in scope, </li></ul></ul><ul><ul><li>And upgrades and capacity planning much easier </li></ul></ul>
  • 43. Dedicated Machine (cont.) <ul><li>Sites that grow from a small company to a larger one generally end up with one central administrative machine . </li></ul><ul><ul><li>Eventually, this machine will have to be split up and the services spread across many servers because of increased load . </li></ul></ul><ul><ul><li>IP address dependencies are the most difficult to deal with when splitting services from one machine to many. </li></ul></ul><ul><ul><ul><li>Name service (e.g., DNS, NIS), Security service (e.g., router of firewall rules ), etc . </li></ul></ul></ul>
  • 44. 3.2.3 Full Redundancy <ul><li>Consider which services will benefit your customers most to have completely redundant and start there. </li></ul><ul><ul><li>Name service and authentication services are typically the first services to have full redundancy. </li></ul></ul><ul><ul><ul><li>They are designed for secondary servers </li></ul></ul></ul><ul><ul><ul><li>they are so critical </li></ul></ul></ul><ul><ul><li>Other critical services, such as e-mail, printing, and networks , tend to be considered much later because they are more complicated or more expensive to make completely redundant. </li></ul></ul>
  • 45. Full Redundancy <ul><li>Another benefit of full redundancy </li></ul><ul><ul><li>It makes upgrade procedure easier. </li></ul></ul><ul><ul><ul><li>A “ rolling update” can be performed </li></ul></ul></ul><ul><li>Case Study: Design Email services for Reliability </li></ul><ul><ul><li>Incoming mail path vs. Outgoing mail path </li></ul></ul><ul><ul><ul><li>Mail relays vs. mail routing hosts </li></ul></ul></ul><ul><ul><ul><li>Mail delivery hosts </li></ul></ul></ul><ul><ul><li>Firewall </li></ul></ul>
  • 46. Appendix <ul><li>Background - Internet Applications </li></ul><ul><li>Networking Troubleshooting Process </li></ul><ul><li>Case Study: </li></ul><ul><ul><li>E-mail system operations and design considerations </li></ul></ul><ul><ul><li>Security events </li></ul></ul>
  • 47. Background - Internet Applications
  • 48. Truth Depends on Interpretation (e.g., Anti-spam or anti-virus mail filtering ) Filtering with H 1 (msg) Filtering With H 2 (msg) Mail Spool Discard <ul><li>MTA 1 (or MUA 1 ) </li></ul>Accep t <ul><li>MTA 0 </li></ul><ul><li>MTA = Mail Transfer Agent </li></ul><ul><li>MUA = Mail User Agent </li></ul><ul><li>MTA 2 (or MUA 1 ) </li></ul>
  • 49. Internet <ul><li>Bouncing server </li></ul><ul><li>Incoming SMTP Gateway Farm </li></ul><ul><li>Mail Spool </li></ul><ul><li>server </li></ul><ul><li>Outgoing SMTP Gateway Farm </li></ul><ul><li>Firewall </li></ul>典型 E-mail 系統運作圖 <ul><li>SMTPauth </li></ul><ul><li>Mail Filtering </li></ul><ul><li>BL/GL/WL </li></ul><ul><li>Auto-learn </li></ul>
  • 50. MTA LDA Mail spool Internet POP3/IMAP server MUA user Mail storage Anti-virus programs Incoming Flow of a Typical Mail System <ul><li>User PC </li></ul><ul><li>procmail </li></ul><ul><li>sendmail </li></ul><ul><li>Netscape, </li></ul><ul><li>MS-outlook, etc. </li></ul><ul><li>A Typical Mail System </li></ul>
  • 51. <ul><li>Incoming </li></ul><ul><li>SMTP Gateway </li></ul><ul><li>SMTP </li></ul><ul><li>POP3/IMAP </li></ul>SMTP <ul><li>Outgoing </li></ul><ul><li>SMTP Gateway </li></ul><ul><li>source </li></ul><ul><li>destination </li></ul>Firewall, filtering Firewall, filtering Generic E-mail Transmission Path 1 2 3 4 5 6
  • 52. A Hybrid Model for Anti-spam -- Generic Mail Filtering Generic Mail Filtering White List Black List Automatic SPAM Learning Reject Mail Spool <ul><li>Accept </li></ul>Grey List (1) (2) (3) (4) Pass Pass Fail Fail Fail temporarily Client Update <ul><li>Discard </li></ul><ul><li>Bounce </li></ul>
  • 53. Sample Statistics anti-spam in mail.TN.edu.tw (http://ms2.tn.edu.tw/report/day/ ) All Msg. 73% Rejected 27% Greylist 25% ClamAV SpamAssassin 2% Virus 3% 17% 5% Passed Blocked SpamLevel &gt; 16 Passed SpamLevel (6-15)
  • 54. Networking Troubleshooting Process DNS_b DNS_a SMTP_a SMTP_b DNS Filtering DNS Filtering Router/Switch Filtering Router/Switch Filtering SMTP Filtering SMTP Filtering Client Router_a Router_b
  • 55. Port-scanning summary on DNS servers of neighbor sites
  • 56. 竹苗區網 DNS server 入侵事件 - Sample scenario <ul><li>2000 年 , 某校在區網的網域 , 登錄有兩個 DNS servers </li></ul><ul><ul><li>不過 , 從一開始 , 就只有建立一個 server </li></ul></ul><ul><li>該 server-A 有 security hole, 被外來者闖入 </li></ul><ul><ul><li>入侵者 , 持續透過該 server-A, 嘗試入侵國外網站 </li></ul></ul><ul><ul><li>由於該單位未設立 abuse, postmaster 等標準聯絡信箱 , 且該機器的 root mail 根本無人處理 </li></ul></ul><ul><ul><li>網域上層 , 持續收到國外不同地方轉來的抱怨與求助 e-mail </li></ul></ul><ul><li>從區網的 router 統計數字 , 發現該校有大量異常的 DNS 流量 </li></ul><ul><ul><li>往國外地區 ( 東歐 ) </li></ul></ul>
  • 57. <ul><li>DNS </li></ul><ul><li>Server </li></ul><ul><li>farm </li></ul>.com .arpa Others <ul><li>DNS </li></ul><ul><li>server </li></ul><ul><li>Caching-only </li></ul>www, proxy SMTP Layer-1 Layer-2 <ul><li>Ordinary </li></ul><ul><li>client </li></ul>Multiple outgoing paths and distributed DNS Internet ISP-2 ISP-1
  • 58. Traffic Amplifying Attacks via DNS Zone Transfer A: Attacker V: attacked site ( Victum) D1 D2 Dn Q: zone transfer Dn: n - &gt;some large number Q(n) R(n) R(1) R(2) Q(1)
  • 59. Common Terms <ul><li>Reliability ( 可信度 , 可靠性 ) -- From Wikipedia, </li></ul><ul><ul><li>In general, reliability (systemic def.) is the ability of of a person or a system to perform and maintain its functions in routine circumstances , as well as hostile or unexpected circumstances . </li></ul></ul><ul><ul><li>The IEEE defines it as &amp;quot;. . . the ability of a system or component to perform its required functions under stated conditions for a specified period of time .&amp;quot; </li></ul></ul>
  • 60. Common Terms <ul><li>In telecommunications and reliability theory , the term availability has the following meanings: </li></ul><ul><ul><li>1. Simply put, availability is the proportion of time a system is in a functioning condition . </li></ul></ul><ul><ul><ul><li>Note 1: The conditions determining operability and committability must be specified. </li></ul></ul></ul><ul><ul><ul><li>Note 2: Expressed mathematically, availability is 1 minus the unavailability . </li></ul></ul></ul>
  • 61. Common Terms <ul><li>In telecommunications and reliability theory , the term availability has the following meanings: </li></ul><ul><ul><li>2. The ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval. </li></ul></ul><ul><ul><li>Note 1: An example of availability is 100/168 if the unit is capable of being used for 100 hours in a week. </li></ul></ul><ul><ul><li>Note 2: Typical availability objectives are specified either in decimal fractions , such as 0.9998, or sometimes in a logarithmic unit called nines , which corresponds roughly to a number of nines following the decimal point, such as &amp;quot; five nines&amp;quot; for 0.99999 reliability. </li></ul></ul>
  • 62. Definition of availability <ul><li>Barlow and Proschan [1975] define availability of a repairable system as &amp;quot;the probability that the system is operating at a specified time t .&amp;quot; </li></ul><ul><li>Representation </li></ul><ul><ul><li>The most simple representation for availability is as a ratio of the expected value of the uptime of a system to the aggregate of the expected values of up and down time , or </li></ul></ul>

×