Many ISPs offer server “co-location” – which simply means that your server is housed on their premises, located alongside servers belonging to other clients.
Under this scenario, either you can hire the ISP to administer the server, or you can take on some or all of the server administration responsibilities yourself.
Here are reasons why you might choose server co-location over running a server on your premises:
The ISP has faster or more reliable connectivity to the greater Internet.
The ISP has a better physical environment for the server – better environmental conditions, better security, etc.
The ISP can perform regular tasks, such as backup, restarts after failure, or security monitoring, on a 24 hour basis.
Co-location differs from the virtual host option. Under co-location, typically you buy and own the server hardware. Under the virtual host option, typically you rent a share of the server resources under your own domain name.
External Service Provider Caveats
You need to do some up-front research and negotiation before you decide to put your content on an external server. Here are some caveats:
Have a clear agreement that states that you own your own intellectual property: the content that you put on the Web site, the domain name you register, etc.
Make sure you have access to server log information, including all raw data, and that you can access this data as frequently as you want. Many commercial host content services charge extra for access to the logs. You may be willing to pay the fees, but be sure they are within your budget.
Be sure you understand all fees in general.
General (lot. generalis - umumiy, bosh) - qurolli kuchlardagi harbiy unvon (daraja). Dastlab, 16-a.da Fransiyada joriy qilingan. Rossiyada 17-a.ning 2-yarmidan maʼlum. Oʻzbekiston qurolli kuchlarida G.
For instance, many service providers charge more if you exceed certain monthly bandwidth limitations. These costs can surprise you, especially if you begin by serving small HTML documents, then at a later date you decide to offer streaming multimedia. Also you can expect to pay relatively high rates for rented server disk space; in many case one year’s rental would more than buy an equivalent amount of disk. (You are paying not only for the capital cost of disk, but for connectivity, backup, server hardware maintenance, the ISP’s profit, etc.)
Ensure that you will be allowed to run your own CGI scripts or middleware products you need.
Be sure there is a clear understanding of the “exit strategy” for the day when you decide to move your content to another provider, or in-house. For instance, the service provider will give you free access to all content, scripts, configuration information, logs, etc. within one week of your request.
Choosing to Run Your Own Server on Your Premises
Here are reasons why you might want to run your own server:
You want to do sophisticated animations or implement “front end” Web connections with existing databases, and your service provider can’t offer services as efficiently or effectively as you could on-premises.
You have a very large amount of data – so much that it is impractical to move the data to the off-premises server.
You already have an Internet infrastructure in place – for instance, a high-speed link to the greater Internet – and you want to take advantage of that existing infrastructure.
You feel it is inevitable that you will learn server technology, and now is as good a time as any.
Basic Web Publishing Infrastructure
No matter where your server resides, you will need some basic components in your Web publishing infrastructure. This diagram depicts some of the core elements:
Your server is named www.ci.smallville.mi.us. (We’ll discuss server names and Internet domain names in more detail later in this chapter.) Your server has a direct, permanent connection to an Internet Service Provider or ISP. Your users connect to any service provider of their own choice (such as America Online in this example) and across the global Internet to your server.
In essence, your server waits until it “hears” a request for a Web page, then delivers it on demand. That request comes across a TCP session established by your user’s Web browser to your Web server:
Thus, your server needs to know how to “speak” the Hypertext Transfer Protocol (HTTP) in order to understand and process requests to transfer Web documents to the user. Generally speaking, your server does not need to understand anything about HTML in order to deliver content to your users. Your content providers and your authoring tools take care of producing good HTML documents; the server just sees them as files to be sent on demand. (In the case of dynamic documents and live database content, the scenario is somewhat more complicated; the server and associated software will produce HTML content “on the fly.” The HTTP server itself still doesn’t concern itself with that content, but associated tools need to generate correct HTML.)
In order to achieve the publishing mission, you will typically need more components than a simple HTTP server. This diagram depicts some of the pieces you may need:
Here we assume that the Web server is a standalone box dedicated to the function of serving Web pages. It will thus run a “process” or “service” that is capable of listening for HTTP requests and replying to them.
Note that this diagram depicts a box called a “router.” A router is a device that’s capable of deciding which traffic needs to leave the local network, and be “routed” to other networks on the Internet. The router is connected to some sort of Wide Area Network (WAN) adapter, which could vary from a simple ISDN modem to a digital interface for a modern high-speed link.
If you have an existing Internet infrastructure, you already have a router on your premises. Some “server appliances” (discussed later in this chapter) come with their own router functionality built-in; the more typical case is to have a router running in its own box. The leading vendors of routers are Cisco Systems, 3Com, and Bay Networks.
One optional device is not shown in this diagram, and that is the “firewall.” A firewall is a device that filters network activity and rejects traffic that isn’t appropriate for your local network. Firewalls also help monitor traffic and detect attacks on your various servers. Firewall functionality can be built into a router, or you might choose a separate router. While many commercial enterprises run firewalls as a matter of course, many institutions such as libraries and universities historically have chosen not to. Over time as security needs increase, firewalls may become popular in virtually all sites. Today, whether your site incorporates a firewall depends on how you balance concerns about safeguarding information, maintaining open access, and budgetary constraints.
You have a choice of whether to dedicate your Web server to the sole task of serving Web content, as opposed to running multiple ancillary services on the same box. These ancillary services may reside on other servers on your premises, or even on servers hosted off-premise by someone else. If your site is small you may opt to run a variety of ancillary services on a single physical server box. For instance:
Many people find it helpful to spread services out among multiple boxes in order to isolate functions; they argue this improves performance of each function, and minimizes disruptions when servers fail. For instance, in this example, if your external database server goes down, your static HTML content (such as the main home page for your site) could still be available to users.
The choice of how many server computers to install depends on many factors: performance, budget, and the philosophy of the server administrator. In one extreme case, you would run a single Web service and a mechanism for transferring content to the server – and nothing else – on your Web server. In the other extreme case, you might run all of the services shown here on a single piece of server hardware. Most sites will choose between these extremes.
Whether you use a single server or many, note that some of these related services are essential to every Web publishing project. Others may not be necessary for your publishing project. Let’s consider each of these services:
Networking support: Your server must be able to communicate with users on your local network as well as the greater Internet. Modern operating systems now come with built-in support for the Internet standard communications protocol known as TCP/IP, whether a box is a desktop, a laptop, or a server system. Your server will have thus include built-in support for TCP/IP, which in our examples is used both by your content providers on the local network as well as for your Internet users. At initial setup of the server, you’ll need to configure it to talk TCP/IP in your environment by entering certain configuration options and perhaps by installing drivers for your local network and for your connection to the greater Internet. (Think of your local network as your LAN and your Internet connection as your WAN or Wide Area Network..)
Web server software: Your Web server software is a separate tool that runs as its own “service” or “process” on the server. A variety of packages are available; we discuss options later in this chapter.
FTP server software: Most Web sites support FTP (for “File Transfer Protocol”) as a least-common-denominator mechanism for content providers to place new content (HTML files, images in GIF or JPEG format, etc.) on the server. Many sites use FTP as the only mechanism for posting content. FTP can be cumbersome when done “manually” via a line-mode interface; with graphical interfaces, it can be reasonably intuitive.
FrontPage extensions: Microsoft’s popular FrontPage authoring tool requires specialized support in the server so that authorized content providers can publish their content. Microsoft’s Internet Information Server (IIS) supports FrontPage natively. Other server products may do so as well; others may require installation of “extensions” to support FrontPage.
Windows file services: Many shops run a local area network with NT file sharing enabled, so that authorized users can “mount” disks on other computers, including the Web server. This allows content providers to use “drag and drop” operations in Windows to move files or folders to the content station for editing, or to the server for publishing. (Note that Windows-style file sharing can be enabled even for non-Windows Web servers thanks to tools such as Samba. Note also that in a pure Macintosh shop, with Mac servers and desktop computers, you would use Mac-style drag-and-drop file importing and exporting.)
E-mail services: It’s almost impossible to conceive of running an active Web publishing project without a mechanism for team members and users of the site to communicate. Your e-mail service need not reside on the same server as the one that hosts your Web content; indeed, many system administrators prefer not to run e-mail on Web servers for security reasons.
Database “middleware” tools: if you want to offer “live” content by connecting to a database, you’ll need a database middleware product such as Cold Fusion. (For the Toolkit, we use Microsoft Active Server Pages, or ASP, as our middleware.) In order to connect to a live database, you typically would install middleware tools on the Web server itself. If you are not connecting to a live database, you do not need middleware software.
Database server: If you offer a live database, you need database software such as MS-Access, SQL Server, Oracle, Informix, or FileMaker Pro to host the actual database content. It is quite common to run a database on an external box for performance and/or security reasons. In order to communicate with your middleware and in turn your Web server, you will want to run a database that supports the ODBC (Open Database Connectivity) standard. Note that many database products now are shipped with built-in Web middleware.
Backup software: You will want to periodically back up your entire server software environment, and you will want to back up your Web content frequently as well. Backup software allows you to automate this task. You may want to run backup software on the Web server and on each of the servers with production services, or you may want to install a single, centralized network backup service that is capable of accessing all production disk volumes and backing them up as a batch.
Keep in mind that your choices as to what services to run, as well as your how many servers to use, are not carved in stone. You can always add new server hardware, and re-allocate production services among server boxes, as time goes on.