In general, when we discuss the implementation during a XenDesktop or XenApp PVS design, the emphasis is always on the technical aspects of the PVS, eg PVS must be virtual or physical, one or two servers, like NIC, etc. Other questions / answers, however, it may be necessary for a successful implementation to take place. PVS implementation is not only a technical challenge. When dealing with large corporate enterprises, it is crucial to also explain the process of change, such as PVS will provide servers (XenApp) and desktops (XenDesktop)?
The introduction of PVS as OS streaming technology has an impact on all aspects of data centers. This article does not propose a specific solution, rather it should be considered a recommendation based on my personal experience in the field with suggestions on what to consider in design and implementation to succeed.
Other items may include more -depth information on each of the aspects mentioned below
Let's look at the various aspects of implementation :.
1. Networking - Network design is a fundamental part of PVS implementations. PVS operates DHCP and PXE to function properly and be able to distribute the server / desktop operating system (Yep, it's true that ISO image could be used instead of PXE, but it needs resources extra). It would be a good idea to check that the network approves DHCP broadcast service on data center servers networks. For example. are ancillary IP addresses allowed on the current network devices? It is not a major problem from a technical point of view, but in terms of processes and procedures, it could become difficult to ask for exceptions when needed. Hence this should be taken into consideration when dealing with networking designs. Clarify the necessary configurations with networking team can be useful and allow for robust implementation of PVS.
2. - Storage is another key element in data centers. Even when the flexibility of PVS leaves us free to decide whether we want a NAS / SAN or local disk storage as WriteCache, type of IOPS generated should be discussed with the storage team. Some companies define the rules of their DataStore in size and pin count based on the activity of disk IOPS "normal." We know that PVS is slightly different from a normal workload IOPS. It is therefore necessary to define new rules for specific data stores WriteCache for use in conjunction with the storage team.
3. Antivirus - Working with the OS streaming involves one read image is deployed on multiple servers. The image is reset at each reboot state, and so it does not easily become infected. If the operating system is clean when the image is generated, real-time protection is sufficient to protect servers and IO storms on storage (potentially generated from massive regular disk scans) can be avoided. Most new virus take into consideration this kind of deployment scenario, and provide tools that generate hash tables during the generation of the image. In addition, they are able to determine if the files have changed from a virus infection without the file system analysis. These items could be discussed with the client's antivirus team, that would be a good idea to agree on a strategy for the implementation and maintenance of a safe environment, without making radical changes.
4. Deploying Software - In most of the company's businesses, software deployments are implemented by ESD systems. With PVS, the software deployment approach radically changes. Maintaining the software version or install massively on a set of servers means simply "maintain" the version of the OS image. Hence ESD has meaning only when the maintenance of the OS image. There is no reason for the application to be installed on each server continuously. Again, it is important to modify procedures to adapt to new scenarios.
5. CMDB - A basic configuration management database is the repository that keeps track of systems and configurations. A key success factor in the implementation of a CMDB is the ability to automatically discover information about the CIs (auto-discovery), and track changes as they occur. The point is that in environments PVS all virtual machines are identical or at least a well-defined set of images. Therefore, the usual approach to installing an agent inside the virtual machine does not produce the desired results.
Therefore, it becomes necessary to check other ways to get the data. He could not be found in other places such as PVS DB or the hypervisor management DB.
6. Procedure QA - Most companies have a quality assurance process in place, which returns the system from the project phase / application to the operations department before systems are pushed to production . In a PVS environment, virtual machines are based on the same image or set of images, so is it really necessary for each VM through the quality assurance process? Probably the basic image and each later should go through QA. In addition, some software components such as AV agent, backup agents, etc. may be missing or installed with various configurations (as described above). Any changes must be discussed with the quality assurance team, and agree with the operations department, which will support the production environment.
7. Security - Security is another important aspect of the discussion PVS, particularly with regard to environments where customers want to have multi-tenancy using only a single implementation by operating environments. Here the problem is more technical than the procedure, however, explaining the various techniques that consultants are able to implement to create secure environments, could help speed up the project approval process.
0 Komentar