The overall architecture of the App Orchestration Technology was discussed in a blog post earlier in this series. In this blog, I'll cover more details on the App Orchestration Workflows and technological agents.
A traditional management system is task-based, where changes in the managed systems are attempted immediately and all problems should be resolved at this time. However, App Orchestration implements a desired state system, where changes in the managed systems are made online, using workflow. This allows operations to be retried or even executed again by ensuring that compliance is achieved.
A workflow in the App Orchestration Technology is broken down into steps, where each step might be assigned to another function of the agent type and scale of the operation. Generally, there is an App Orchestration Agent in each box requiring configuration changes. For example, there will be an Active Directory agent, XenApp agent and a web interface agent. These agents could be located in an area that has access to the management APIs for the corresponding products. In this version of the App Orchestration, the Active Directory agent resides in the same box as the App Orchestration Engine. The XenApp agent resides in each of XenApp controller boxes. The hosts of the XenApp session does not require an agent service. Finally, the agent Web Interface resides in the area of the Web interface.
Each step of the workflow generated by the Orchestration Engine component is assigned to specific agents depending on the task and scope of the operation. All agents to continuously monitor the configured intervals if new workflow steps are assigned to their own specific agent instance. Progress in the tasks referred to the Orchestration engine during startup. Any agent can be assigned multiple stages of workflow simultaneously. The agent is able to perform all tasks in parallel up to a maximum limit of gas, which is configurable. The default value is 20 concurrent tasks.
A task can be long running, but there must be a report of the current situation. Otherwise, when the maximum allowed time expires, the workflow will be canceled. The timeout value is configured and defaults to 60 minutes. When workflows are completed, they will be retried automatically or manually again. This is possible because each workflow was implemented to be idempotent. The configuration can be partially or even completely. In each case, the workflow executes only what is necessary to comply with the desired state.
Another case where the workflow is completed by the agent when it is impossible to report the progress. When the maximum number of login failures is exceeded, the agent will terminate all running processes because it is impossible to account for the status of these tasks more. The maximum number of failures is configured by default and to 5 attempts. All of these options the enforcement agent is stored in the registry, but they can be changed using the Set-CamAgentConfiguration cmdlet exported by CitrixCamAgent module installed with the agent.
The App Orchestration administrator can monitor the execution of the workflow using Citrix App studio console. Different operations are possible depending on the workflow state. Workflows can be canceled even if the agent has already started treatment later. When the workflow fail, they can also be retried. Depending on the error, sometimes manual intervention may be necessary, such licensing. In this case, retry the workflow will allow you to pick-up agent workflow again. When workflows are successful, they are moved into the story so that the current number of active workflows manageable.
When an officer loses connectivity with the Orchestration Engine, a new agent with the same role will be elected if possible. In this case, the home agent will be marked as unavailable and no new workflow will be affected. If it is possible to resolve connection problems, the agent will resume voting for the tasks, but will be used only as a backup at this point.
All information that the agent should perform a specific configuration task is included with the workflow. Some workflows also require the officer to use specific credentials. However, this information is not included in the workflow. In this case, the agent queries the Orchestration Engine for the credentials required. This request is made on a secure connection (HTTPS).
There are an agent role for the agent that executes the same machine as the Orchestration Engine. This agent has an integrated workflow that monitors the import UO configured for new machines to be imported.
The agents that are installed on other machines (such as a XenApp server), do not automatically start polling for all attempts link will be rejected until App Orchestration adds this machine as a valid agent. This occurs after the machine is successfully imported and abilities are validated.
The agent includes a PowerShell module that can be used to customize settings, such as polling interval and executing timers work as described above. All parameters correspond to the registry entries that can be configured using policies to propagate these changes to all machines of the agent. The module name is CitrixCamAgent and cmdlet to configure it Set-CamAgentConfiguration. Help is available for this cmdlet along with other cmdlets agent.
You can customize any workflow by replacing the default implementation, or even part of it. The agent module exports several cmdlets and none of those could be customized by loading an extension script file or set of files. The location of these files is also configurable with the agent module or with a registry key. Please refer to the configuration applet described above.
An example of customizing a workflow has to do with the strict validation of the workload of machines from a catalog. The default validation ensures that the machines in the catalog are identical in terms of installed applications and also operating the system updates and configuration of applications that could affect the launch of the application, such as the file type associations. To change this validation, the Test-CamWorkloadMachineCapability cmdlet could be modified to implement a different validation. This cmdlet takes two string parameters with the XML data is expected and actual data read from the image of the machine. The cmdlet then returns the differences between the two. By default, they should be identical, but this rule can be modified if necessary. In the simplest case, you can always ignore differences by creating a function that returns nothing, as follows:
Function Set-CamWorkloadMachineCapability {}
The new definition of the function can be saved in a script file (ps1) and saved in a folder. The agent can then be configured to load the script files in this folder by using the Set-CamAgentConfiguration cmdlet. The new implementation will be used instead of the original. Note that the machine script execution policy may require changes to load unsigned scripts. This can be done with the Set-ExecutionPolicy cmdlet.
Note that the above case is just for illustration and is not recommended because it is very important that all machines in a catalog are identical to ensure a consistent user experience regardless of the specific machine used for delivery of an application or desktop. More details on other customizations will be explained in another post.
In future posts, I'll cover the more detailed customizations and explain the implementation of specific workflows.
This blog is part of a series on the application orchestration. For the remaining articles in this series please refer to these articles:
• Concepts
• The architecture
• The Provisioning machines. Part 1 and 2
• Management of tenants (to come)
• Classified Management
• Manage Subscriptions (forthcoming)
• Patching workload Machinery (coming soon)
• Understanding Workflows. Part 1 (this article) 2 and 3
• Troubleshooting (forthcoming)
• Integration with CloudPortal Services Manager (forthcoming)
0 Komentar