• General Support Criteria
  • Support Summary
  • Recommendations
  • Red Hat Enterprise Linux Notes

    Download 51 Kb.
    Hajmi51 Kb.
      1   2   3   4   5   6

    TSS Linux Support

    Information current as of August 26, 2003
    [Please send comments, suggestions and questions to dennis@stanford.edu]

    This document describes our options and recommendations for supporting the Linux operating system on our servers.

    Issues not addressed by this document:

    Campus distribution and support of our Linux server solution

    Hardware standards

    Software repositories

    Application requirements

    Mature and dependable server-build methods

    Availability of test environments
    General Support Criteria:

    • Frequency of major releases

    • Availability and timeliness of fixes and security patches

    • Staff training

    • Availability of off-hours support for critical production systems

    Support Summary:

    There are three approaches to supporting Linux on our systems:

    • Purchase Red Hat support

      1. We can purchase Red Hat support for the AS, ES or WS releases, and add the Stanford modules ourselves.

      2. Red Hat support is purchased for each server on an annual subscription basis.

      3. The Red Hat support contract guarantees response times and off-hours support, depending on the support package.

      4. Red Hat support guarantees a release schedule between major versions of 12 to 18 months.

      5. Red Hat support guarantees up to 5 years of support per version.

    • Rely on Open Source community support

      1. There’s no direct cost for support or for the OS.

      2. Support depends on internet volunteers and in-house knowledge.

      3. There are no guaranteed response times, but historically it has been good.

      4. Off-hours support is uncertain.

      5. Public releases have an aggressive release schedule – 4 to 6 months between the public releases, with support lasting 1 year.

      6. Since Red Hat will support the public releases for just one year, long term support beyond a year depends on internet volunteers.

    • Develop in-house Linux expertise

    1. No direct cost other than in further training of staff.

    2. We can to a degree guarantee response times and off-hours support.

    3. We can to a degree support our own release schedule and how long we continue support.


    We recommend adopting all three approaches. Each server and service should be evaluated and the support level set according to the requirements of the particular server.

    Some general criteria to use in determining support levels:

    Criticality of production – does supporting the service require 7x24 hr support?

    Yes – Red Hat AS with premium support

    No – Red Hat or open source

    Server redundancy – can a single server go down without affecting service?

    Yes – open source

    No – Red Hat or open source

    Application requirements – does the app require advanced server features?

    Yes – Red Hat AS

    No – Red Hat or open source

    Number of CPUs in the server:

    Greater than 2 – Red Hat AS, or open source

    1 or 2 CPUs – Red Hat or open source

    Oracle Database servers: Red Hat AS premium

    Oracle Database development servers: Red Hat AS standard

    A group of identical web servers (web farm): open source

    Four CPU server: either Red Hat AS or open source

    Email servers: open source

    Application server: Red Hat AS or ES standard

    Redundant application servers: open source

    Download 51 Kb.
      1   2   3   4   5   6

    Download 51 Kb.