Fix for fling bug The customer bug on the fling, exposed an un handled scenario. This scenario has now been addressed with this update. No similar flings found. Check these out instead Jan 07, Power vRA Cloud. Mar 16, Horizon View. Jun 18, Load Analysis Tool. Because you have two nodes in a cluster and you need an odd number of voting elements, create a file share quorum witness, which will cast the third vote. A file share witness is recommended when you need to consider multi-site disaster recovery with replicated storage.
When you finish this step, you have two files shares: one for Site 1 and one for Site 2. For detailed instructions, see Configure and manage quorum. This procedure focuses on the specific settings required for connecting App Volumes to a highly available database. Important: If you see an error message such as the following one, it means you need to enable named pipes, as described in Step 1.
With App Volumes successfully installed, you can begin configuration. The procedures in this appendix create a setup in which the App Volumes database can fail over automatically within each site. Site 1 and Site 2 have separate databases, but during a failover, users at Site 1 will be able to use replicated App Volumes packages in Site 2 as long as the user entitlements are also replicated. For configuration details, see the section, Replicate Application Packages and Reconstruct Relationships and Entitlements.
You can configure writable volumes so that end users can determine how much free disk space is available in their writable volume. You can expand the amount of disk space if necessary. Administrators can use the App Volumes Manager console to view the disk space remaining in writable volumes.
Administrators can also allow end users to see how much disk space is available on their writable volume by looking at their system volume. To do this, administrators must create a new registry key during the App Volumes Agent configuration:. This change requires a reboot to take effect.
Logging out or logging in does not apply the changes. When end users look at available disk space through Windows Explorer before you make the registry changes, they can see the free space and total space reported for the C: drive. Configuring the registry so end users can view free space on their writable volumes is recommended any time you use writable volumes.
The default writable volumes template in App Volumes 4 is 10 GB. To expand the writable volume for each user from the App Volumes Manager console:. Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:.
This message will close in seconds. You are about to be redirected to the central VMware login page. To use this setup, perform the procedures described in the sections that follow. After the NFS datastore has been added to the vSphere hosts, click Rescan to make it available as a managed storage location.
Select the datastore, and click Make As Not Attachable. This option allows packages to replicate to and from this datastore, but prevents packages on this datastore from being mounted for use. Create a Storage Group Next, you create a storage group that includes one or more attachable datastores, and the non-attachable datastore, as shown in the following screenshot.
Figure 1: Creating a Storage Group Replicate Packages from Site 1 to Site 2 After storage groups have been created on Site 1 and Site 2, you can import packages for assignment at the secondary site, and you can replicate the packages to the datastores that are members of the storage group.
Figure 2: Import and Replicate Packages. Replicate Application Packages and Reconstruct Relationships and Entitlements App Volumes 4 introduced the constructs of applications, packages, markers, and other components comprising simplified application management SAM , to streamline the process of managing the application lifecycle. The following example is meant to illustrate the issue. Manual Replication This section outlines the high-level tasks needed to replicate relationships and attributes.
Figure 6: Delete the Replicated Application After Moving Its Package to an Application with the Correct Name Once the application-to-package relationships match that of the primary site, re-apply the following attributes to the application and packages so that they match those of the primary site.
When inconsistencies are found, you can use the Fix Apps option, which performs the following tasks: Creates applications at the secondary site that match those at the primary site Moves the imported packages to the new applications Deletes any remaining, empty application objects Once the application-to-package relationships are consistent, you can then sync entitlements from Site 1 applications to their matching Site 2 applications.
At Site 2, we created VMs named s2-sql4 and s2-sql5. Inside the OS, the disks are mapped to drive letters as follows. In preparation for creating the failover cluster, choose a cluster name and obtain a corresponding static IP address for the cluster in Site 1 and in Site 2. In the wizard, select to add the following features:.
NET Framework 3. Instance Configuration page — Select Default instance. On the Data Directories tab, for each item, select the disk that you created for that type of file during VM creation.
Use the following screenshot as a guide. Writable volumes were created for and assigned to end users who required the ability to install their own applications. Writable volumes provide added flexibility for end users who are permitted to install software outside of the IT-delivered set of applications. The UIA-only template ensures application installation and configuration data is stored, while profile data is managed using other technologies.
If a writable volume becomes corrupt, applications can be reinstalled without the risk of data loss. Writable volumes are read-write. Storage utilization patterns are largely influenced by user behavior with regard to desktop logins and logouts, user-installed applications, and changes to local user profiles. Group each set of similar users into use cases, and evaluate performance based on peak average use.
VMware recommends designing multi-site implementations using a separate-databases, or multi-instance model. This option uses a separate SQL Server database at each site, is simple to implement and allows for easy scaling if you have more than two sites. Additionally, latency or bandwidth restrictions between sites have little impact on the design.
In this model, each site works independently, with its own set of App Volumes Managers and its own database instance. During an outage, the remaining site can provide access to packages with no intervention required.
For detailed information on the failover steps required and the order in which they need to be performed, refer to Failover. An NFS datastore was used as a common datastore among the storage groups to facilitate cross-site package replication. The separate-databases option is the most resilient, provides true redundancy, and can also scale to more than two sites. With packages replicated between sites, the packages are available for use at both locations. In use cases where writable volumes are being used, there are a few additional steps:.
All assignments to writable volumes are successfully added, but to the new valid location. The following recommendations pertain to golden image optimization, setting up virtual desktops, and security best practices. The OS Optimization Tool includes customizable templates to enable or disable Windows system services and features, per VMware recommendations and best practices, across multiple systems.
Because most Windows system services are enabled by default, the OS Optimization Tool can be used to easily disable unnecessary services and features to improve performance. To support a large production environment, there are some important security configurations that administrators should put in place:.
The following table lists the versions used in this reference architecture. This document outlines the initial setup and configuration process. After installation is complete, you must perform the following tasks to start using App Volumes:. Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:.
This message will close in seconds. You are about to be redirected to the central VMware login page. Justification This strategy allows the design, deployment, and integration to be validated and documented. Any kernel mode applications should reside in the base image and not in a package. Note : Packages are very read intensive.
Storage groups may still be applicable to vSAN customers for replicating packages. Place packages on storage that is optimized for read percent read. Assign as few packages as possible per user or device. Although most of the content is applicable to App Volumes 4, the maximum number of package attachments tested has increased. App Volumes 4 defaults to an optimized Machine Managers configuration. Use the default configuration and make changes only when necessary.
Network Ports for App Volumes A detailed discussion of network requirements for App Volumes is outside of the scope of this guide. Consider the Horizon block design and scale when architecting App Volumes. Justification Standardizing on the pod and block approach simplifies the architecture and streamlines administration. In a production Horizon environment, it is important to adhere to the following best practices: Sizing and scaling best practices, as documented in the Horizon Architecture Planning guide vSphere scalability best practices, as documented in Performance Best Practices for VMware vSphere 7.
Scalability and Availability As with all server workloads, it is strongly recommended that enterprises host App Volumes Manager servers as vSphere virtual machines. App Volumes Managers App Volumes Managers are the primary point of management and configuration, and they broker volumes to agents. Justification This strategy satisfies the requirements for load and provides redundancy. Multiple vCenter Server Considerations Configuring multiple vCenter Servers is a way to achieve scale for a large Horizon pod, for multiple data centers, or for multiple sites.
Multiple AD Domain Considerations App Volumes supports environments with multiple Active Directory domains, both with and without the need for trust types configured between them. To support optimal performance of packages and writable volumes, give special consideration to the following host storage elements: Host storage policies Storage network configuration HBA or network adapter NFS configuration Multipath configuration Queue-depth configuration For best results, follow the recommendations of the relevant storage partner when configuring hosts and clusters.
Justification The load balancer properly distributes load and keeps the services available in the event of an issue with one of the managers. No additional configuration is required on the App Volumes Manager servers.
Justification An Always On availability group achieves automatic failover. Storage A successful implementation of App Volumes requires several carefully considered design decisions with regards to disk volume size, storage IOPS, and storage replication. Package and Writable Volume Template Placement When new packages and writable volumes are deployed, predefined templates are used as the copy source.
Free-Space Considerations Package sizing and writable volume sizing are critical for success in a production environment. The option to restrict writable volume access and thus initial creation to a certain desktop or group of desktops can also mean that user login behavior dictates when a writable volume template is copied.
Storage Groups App Volumes uses a construct called storage groups. The two types of storage groups are: Package storage groups — Used for replication. Writable volume storage groups — Used for distribution. Two automation options for package storage groups are available: Automatic replication — Any package placed on any datastore in the storage group is replicated across all datastores in the group.
Automatic import — After replication, the package is imported into App Volumes Manager and is available for assignment from all datastores in the storage group. Multi-site App Volumes Implementations and Storage Groups Storage groups can also be used to replicate packages from one site to another in multi-site App Volumes configurations. Writable Volumes and Storage Groups Writable volume storage groups are used to distribute volumes across datastores to ensure good performance as writable volumes are added.
Table 8: Implementation Strategy for Storage Groups Decision Storage groups were set up to replicate packages between datastores. Packages This section provides guidance about creating, sizing, scaling, provisioning, configuring, and updating packages. Packages at Scale The number of packages that can be attached to a given VM is technically limited by the maximum number of possible drive attachments in Windows and vSphere.
Attaching packages involves the following processes: The disk mount mounting the package VMDK to the VM The virtualization process applied to the content in the package merging files and registry entries with the guest OS The time required to complete the virtualization process varies greatly, depending on the programs contained in a given package. The following is a simple example for grouping App Volumes programs into packages: Create a package containing core programs apps that most or all users should receive.
This package can be assigned to a large group or OU. Create a package for departmental programs apps limited to a department. This package can be assigned at a group or departmental level. Use storage groups for packages when packages are assigned to a large population of users or desktops. Storage groups for packages are not applicable in a vSAN implementation. For example, the packaging VM and target should be at the same OS patch and service pack level and, if programs are included in the golden image, they should also be in the packaging VM.
Do not use a packaging machine where you have previously installed and then uninstalled any of the programs that you will capture. Uninstalling a program might not clean up all remnants of the software, and the subsequent App Volumes package capture might not be complete. Always take a snapshot of your packaging VM before packaging or attaching any packages to it. If any packages have been assigned to the VM, or if the VM has been used previously for packaging, revert that VM to the clean snapshot before creating a new package.
Updating and Assigning Updated Packages Recommended Practices App Volumes 4 introduced assignment types called marker and package to improve the administrative process of updating application packages. Consider the following best practices when updating and assigning updated packages: When creating and updating packages, use the Stage drop-down list to select an appropriate value. This makes it easy for you and other App Volumes admins to manage the lifecycle of the package.
Use the marker assignment type to simplify updates for your general population of users. Use the package assignment type for one-off, explicit assignments of a specific version.
Note : If both package and marker assignments are made, the package assignment is used. Horizon Integration Although not required, App Volumes is often implemented in a Horizon environment. Do not attempt to include the Horizon Agent in an App Volumes package. The Horizon Agent should be installed in the golden image VM.
You must uninstall the Horizon Agent if it is present. Dependencies previously installed by the Horizon Agent, such as Microsoft side-by-side SxS shared libraries, are not reinstalled, and therefore are not captured by the App Volumes packaging process. Performance Testing for Packages Test packages immediately after packaging to determine their overall performance. ThinApp Integration with Packages Network latency is often the limiting factor for scalability and performance when deploying ThinApp packages in streaming mode.
Office Plug-Ins and Add-Ons The most straightforward method is to include Microsoft Office plug-ins or add-ons in the same package as the Microsoft Office installation. Recommended Practices for Installing Office VMware recommends that you install core Microsoft Office applications in the base virtual desktop image, and create one package for non-core Microsoft Office applications, such as Visio, Project, or Visio and Project together.
Application Suitability for Packages Most Windows applications work well with App Volumes, including those with services and drivers, and require little to no additional interaction.
Applications That Work Best in the Golden Image Applications that should be available to the OS in the event that a package or writable volume is not present should remain in the golden image and not in an App Volumes virtual disk.
Applications Whose Components Are Not Well Understood In the rare event that an issue with an application does present itself, it is important to have a thorough understanding of how the application functions.
Other Special Considerations The following guidelines will also help you determine whether an application requires special handling during the virtualization process or whether virtualization in a package is even possible: Additional application virtualization technologies — Other application virtualization technologies Microsoft App-V, ThinApp, and others should be disabled during packaging because the filter drivers could potentially conflict and cause inconsistent results in the packaging process.
Mixing of and bit OS types — The OS type or bit of the machine that the package is attached to should match the OS type that applications were packaged on. Mixing of application types in App Volumes environments follows the same rules as Windows application types—that is, if a bit application is certified to run in a bit environment, then App Volumes supports that configuration also.
Exceptional applications — Some software apps just do not work when installed on an App Volumes package. There is no list of such applications, but an administrator might discover an issue where an application simply does not work with App Volumes. In summary, most applications work well with App Volumes, with little to no additional interaction needed.
However, you can save time and effort by identifying potential problems early, by looking at the application type and use case before deciding to create a package. Writable Volumes Writable volumes can be used to persist a variety of data as users roam between nonpersistent desktop sessions. Note the key differences between packages and writable volumes: Package VMDKs are mounted as read-only and can be shared among all desktop VMs within the data center.
Writable volumes are dedicated to individual users and are mounted as the user authenticates to the desktop. Writable volumes are user-centric and roam with the user for nonpersistent desktops.
Writable Volume Templates Several writable volume templates are available to suit different use cases. Table 9: Implementation Strategy for App Volumes Writable Volumes Decision Writable volumes were created for and assigned to end users who required the ability to install their own applications.
The UIA-only writable volume template was used. Justification Writable volumes provide added flexibility for end users who are permitted to install software outside of the IT-delivered set of applications. Performance Testing for Writable Volumes Writable volumes are read-write. Multi-site Design Using Separate Databases VMware recommends designing multi-site implementations using a separate-databases, or multi-instance model.
Load balancers — Each site has its own namespace for the local App Volumes Manager servers. This is generally a local load balancer virtual IP that targets the individual managers.
Storage groups — Storage groups containing a common, non-attachable datastore can be used to automatically replicate packages from one site to the other. This common datastore must be visible to at least one vSphere host from each site.
Note: In some environments, network design might prevent the use of storage group replication between sites. Entitlement replication — To make user-based entitlements for packages available between sites, you can reproduce entitlements at each site. You can either manually reproduce the entitlements at each site or use the App Volumes Entitlements Sync tool, provided on the VMware Flings site. For instruction, see the App Volumes Configuration chapter. Manually reproducing entitlements can be somewhat streamlined by entitling packages to groups and OUs, rather than individuals.
A separate database and App Volumes instance deployment option was used. Justification This strategy provides App Volumes capabilities in the second site. Install the first App Volumes Manager in Site 1. If using Always On availability groups to provide a local highly available database, use the local availability group listener for Site 1 when configuring the ODBC connection. Important : For step-by-step instructions on this process, see App Volumes Configuration.
Complete the App Volumes Manager wizard and add the vCenter Servers for Site 1 as machine managers, including mapping their corresponding datastores. Continue with installing the subsequent App Volumes Managers for Site 1. Add them as targets to the local load balancer virtual IP. Repeat steps 1—3 for Site 2 so that the App Volumes Managers in Site 2 point to the local availability group listener for Site 2, and register the local vCenter Servers for Site 2 as machine managers.
For details on setting up storage groups for replicating packages from site to site, see the Recovery Service Integration section of Service Integration. Replicate package entitlements between sites, as described in the Replicate Application Packages and Reconstruct Relationships and Entitlements section of App Volumes Configuration.
0コメント