Horizon 7를 사용하면 회사에서 현재 사용하는 애플리케이션 프로비저닝 기술을 계속 사용할 수 있고 Mirage를 사용할 수도 있습니다. 서버 CPU 사용 및 스토리지 I/O를 관리하고 사용자가 애플리케이션을 설치하도록 허용되는지 여부를 결정하는 두 가지 추가 고려 사항이 있습니다.
동시에 많은 원격 데스크톱으로 애플리케이션을 푸시(push)할 경우 CPU 및 스토리지 I/O 사용량이 급격히 많아지는 것을 볼 수 있습니다. 이러한 피크 워크로드는 데스크톱 성능에 적지 않은 영향을 미칠 수 있습니다. 모범 사례로 애플리케이션 업데이트를 사용량이 적은 시간 중에 하도록 지정하고, 가능한 경우 데스크톱에 대한 업데이트를 분산시킵니다. 또한 스토리지 솔루션이 그러한 워크로드를 지원하도록 설계되었는지 확인해야 합니다.
회사에서 사용자가 애플리케이션을 설치할 수 있도록 허용하는 경우 현재 정책은 연장할 수 있지만 데스크톱 새로 고침 및 재구성과 같은 View Composer 기능은 사용할 수 없습니다. View Composer에서 애플리케이션이 가상화되지 않거나 반대로 사용자 프로파일 또는 데이터 설정에 포함되지 않을 경우 View Composer 새로 고침, 재구성 또는 재조정 작업이 발생할 때마다 해당 애플리케이션이 삭제됩니다. 많은 경우 설치할 애플리케이션을 완전히 제어하는 이 기능은 이점이 됩니다. View Composer 데스크톱은 성공한 구성을 따르기 때문에 지원하기 쉽습니다.
사용자가 자신의 애플리케이션을 설치하고 원격 데스크톱의 수명이 지속되는 동안 그 애플리케이션을 유지하게 해 달라고 요청하는 경우에는 애플리케이션 프로비저닝에 View Composer를 사용하지 않고 인스턴트 클론과 App Volumes를 함께 사용할 수 있습니다. 다른 해결 방법은 전체 클론 전용 데스크톱을 만들고, 사용자가 애플리케이션을 설치할 수 있도록 한 다음 사용자 설치 애플리케이션을 덮어쓰지 않고 Mirage를 사용하여 데스크톱을 관리 및 업데이트하는 것입니다.
