In the test environment that you use to test RIS features, RIS performance, and the installation process, RIS server placement is not critical. For example, you can place the RIS server and other supporting components, such as Active Directory, DNS, and DHCP all on a single server. For more information about creating a RIS test environment, see "Designing a Test RIS Environment" later in this chapter.
In the production environment of a large organization, an all-in-one configuration is not recommended because high RIS traffic volumes can cause significant performance degradation in other services on the server that hosts RIS. This can occur when Server Message Block (SMB) traffic from the server to numerous clients in the setup process precludes other traffic on the network. This results in inhibiting DHCP traffic, new PXE requests, other TCP/IP network traffic, and even some Active Directory replication modes. When the performance of DHCP degrades, this can slow the network or even bring it down. For these reasons, avoid configuring production domain controllers with multiple roles that include RIS, Activ 23423x2319x e Directory, DNS, and DHCP.
To assure adequate performance in a large organization, consider using separate computers in your production environment for the following components:
Domain controller with Active Directory and DHCP
DNS
RIS server
In relatively small organizations, placing your DHCP and RIS servers on the same computer is a common practice and works well in most situations. However, you need to be aware that whenever your RIS server approaches its maximum capacity to handle PXE requests, you might begin to see a failure in the ability of your DHCP server to service client DHCP requests. For further information about combining DHCP and RIS, see "DHCP and RIS Server Considerations" later in this section.
Also observe the following guidelines when placing your RIS server(s) in the production environment:
Do not place RIS on the same computer that is running Exchange Server or Microsoft SQL ServerT.
The high traffic levels of RIS can degrade the performance of these products, and vice versa.
You cannot host RIS on a computer in a wireless network.
Do integrate RIS into networks with preexisting third party remote installation servers.
RIS technology allows the coexistence of remote installation servers from multiple vendors on the same physical network. When you set RIS servers to ignore boot requests from unknown clients, you can introduce them on a network without interfering with preexisting remote installation servers that use the same remote boot protocols.
Because PXE-enabled RIS clients use the DHCP discovery mechanism to obtain a network (IP) address and to locate RIS servers, the relationship of RIS to DHCP in your organization can play a key role in determining your RIS server placement strategy.
In simple environments, a common solution is to add RIS to each DHCP server in use. When you use a combination Windows Server 2003 DHCP/RIS server approach, this reduces the number of initial network packets that RIS clients send to the DHCP and RIS servers. This also increases the server's initial response time. In addition, combining a Windows Server 2003 DHCP and RIS server provides simultaneous answering of client requests. This creates a simplified form of load balancing, because it takes advantage of existing groupings of client computers associated with the DHCP server. This configuration also simplifies troubleshooting and administrative procedures.
|
|
|
Important If the RIS server and DHCP server coexist on the same computer and the RIS server becomes too busy to answer PXE requests, then the DHCP server also becomes too busy and cannot answer IP address requests. However, this issue might be significant only in relatively large organizations. |
Because RIS servers can generate large network loads, they often require high-end hardware and usually must be located near the clients they service. By contrast, a DHCP server generates far less traffic, does not typically require high-end server hardware, and is often centralized rather than near client computers. In a centralized configuration, you might find it impractical to simply add RIS to your existing DHCP servers. In such cases, consider adding RIS services to existing software installation point servers, because they have planning and placement requirements similar to RIS servers.
Also, because the PXE-based remote boot process does not provide a way to determine from which RIS server a client receives service, you need to control which RIS server answers specific clients. This is a primary issue when RIS servers are separate from DHCP servers, or when DHCP servers that are not running Windows Server 2003 are in use. In this situation, the location of RIS clients can have an impact on how you configure RIS server selection and load balancing, and subsequently on where you place a RIS server.
By default, when a PXE-enabled RIS client broadcasts a request for service, all RIS servers receiving the request initiate a reply. The first RIS server on the network from which the client receives a response is the one that provides service to the client. However, combined DHCP/RIS servers have response priority over servers hosting these applications separately. Although this provides a simple form of load balancing among multiple RIS servers available to clients, it is better to balance the load by explicitly restricting which servers can respond to specific clients. This also allows you to prevent specific clients from using RIS servers that you do not intend them to use.
To control server selection, you can physically control network routing so that DHCP discovery broadcasts are forwarded only when appropriate. For example, you might want to forward DHCP broadcasts when a server local to a client is busy or down when the client requests service. By using forwarding to control the routing to a DHCP/RIS server, you can allow answers from only those RIS servers that you configure to receive forwarded client requests.
Another way to control server selection is to configure clients that you prestage in Active Directory to only use a specific RIS server. When a RIS server answers a service request from a client, the server checks the Active Directory forest for the UUID configured in the client computer account to verify whether there is a match to the UUID submitted with the service request. If the RIS server finds a matching computer account, it also checks the account to confirm whether it is configured to use a specific RIS server. If the account designates that only a specific RIS server can provide service, then this is the server that services the client request. The RIS server initially processing the client request then points the client to the RIS server that actually provides the requested RIS services. This is known as a server referral. You can use this mechanism as a simple way to control which RIS servers offer operating system installation services to specific client computers.
For information about combining prestaging and referral capabilities to enhance flexibility and security, see "RIS Server Configuration Design Tasks" later in this chapter.
At this point in your planning process, use job aid "Planning for RIS Servers" (ACIRIS_02.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Planning for RIS Servers" on the Web at https://www.microsoft.com/reskit) to specify the server/software configuration you want to use. Also record the method you intend to use to load balance client service requests to RIS servers (either by configuring routing or using RIS referral servers) and the personnel you want to assign to the task.
Because RIS servers install operating system images on client computers, the amount of traffic the server produces is similar to that of other servers performing as software installation points on your network. However, the amount of RIS server traffic is more predictable than traffic from a general purpose software installation point that provides applications and regular updates. For example, RIS traffic increases when many users are loading images, during deployment of a new operating system or when you add new computers to the network, and decreases after the initial installations are complete.
To accommodate the periodic high traffic volumes that a RIS server generates, you need to place the RIS server in a location that minimizes its impact across your network. In general, place a RIS server near the client computers it services. This localizes the traffic and reduces its impact during times when multiple image downloads occur. If you have an environment in which re-installations occur frequently, you might consider segmenting the physical network to isolate the RIS server and dedicate it to client installations on that segment.
If you have an environment in which you perform a large number of operating system pre-installations before delivery to clients, consider implementing a RIS-based preinstallation lab. A lab such as this allows you to process a high volume of computers by using high-speed networking to reduce installation times. This also avoids any impact on network performance, because you do not have to place your RIS server on the network at all.
For this part of your planning process, use job aid "Planning for RIS Servers" (ACIRIS_02.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Planning for RIS Servers" on the Web at https://www.microsoft.com/reskit) to indicate whether you plan to:
Add your RIS servers to existing software installation points, or DHCP servers.
Create a preinstallation lab for RIS servers.
If you choose to create a preinstallation lab, record the personnel that you assign to the task.
|
