XenDesktop 5 SQL Server Mirror transaction log for larger cause analysis

during the implementation of the XENDESKTOP5 project, it was found that the XENDESKTOP5 version of the database mirroring transaction log was large, in XENDESKTOP4 and The problem does not exist in the XENAPP version, so I'm going to investigate why the XENDESKTOP5 and above versions of the mirrored database transaction logs are so large and how we can maintain such a large database transaction log in the process of our future implementation.

in the In the XenDesktop solution, data processing is handled by a dedicated database for data storage, and there are 3 ways to make the database highly available :

• SQL Mirror

• Virtual machine HA(VMware FT)

• SQL Cluster

According to my inquiry, XenDesktop 4 and above are different from the system architecture of XenDesktop 5, which is why these 2 versions mirror transaction logs.

in theXenDesktop 4version, belonging toCitrix IMAsystem Architecture,MetaFrame XPis the first independent management architecture that uses Citrix (Ima) ofCitrixproducts. MetaFrame XPthat isXenAppthe predecessor. In theImaarchitecture, running the2A protocol, aIca, aIma,Icaprotocols are used to remotely connect desktops and applications, whileImaThe protocol is used to perform functions such as licensing and server load updates, all of which occur between the server and the server and are hidden behind the scenes of the communication protocol. So it can be said thatIcaprotocol is the front-end display protocol for this architecture,Imais behind-the-scenes protocol. In addition,ImaService andCitrixManagement console for communication, allowing administrators to manage and configure the server.

So what does the mirror transaction log have to do with the IMA schema database?

Next, let's explore the IMA architecture of Citrix:

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/39/5C/wKioL1O5-MbwU7BzAAIiZGriCN4434.jpg "title=" 1.png " alt= "Wkiol1o5-mbwu7bzaaiizgricn4434.jpg"/>

This is the architecture diagram for XenDesktop 4 .

In the picture we will find that each host will have the LHC thing, the LHC is the local host cache meaning, in the ima architecture, XD4 and previous versions and XenApp are typical IMA architecture products. IMA Because of the presence of such a LHC , all of his database transaction logs are small.

In the resulting data, it is divided into static information and dynamic information.

static configuration information is stored in the The DB database and the LHC(Local Host Cache) include static information such as Farm configuration information, policy configuration, user and desktop group, desktop group, and virtual machine binding relationships.

　　The dynamic session information is stored in the local LHC and is not updated to the DB. The LHC is the Imalhc.mdb (local Disk file), which is an Access database. Dynamic information includes the registration status, session status, license utilization and other dynamic information of the virtual machine.

While the transaction log of the database is mostly dynamic session information,XenDesktop 4 Because of the schema, the dynamic session information is not written back to the database, it is written to the local host cache, so XenDesktop 4 and the previous version and The XenApp database transaction log does not return very large.

So why is the transaction log for XenDesktop 5 large?

　　

instead of using the IMA data store as the central database for storing configuration information, XenDesktop 5 uses the Microsoft SQL Server database as the data store for configuration information and session information. and XenDesktop 5 belongs to the FMA architecture of Citrix. The FMA architecture has no local host cache, and all data is written to the database, including static and dynamic information.

　　

　　From the above description, we know that XD4 and XD5 have sent a large change in structure, from the IMA management architecture to the FMA management architecture, if XD5 is only an attempt to the FMA management architecture, then XD7 is fully agree with such a management framework, in the new version of XD7, With the combination of XenApp and XenDesktop, Citrix has completely abandoned the IMA management architecture of XenApp and XD4, turning to the FMA management architecture.

and so, The reason whythe Mirror database transaction log is larger from XD5 is that the FMA management architecture does not have a local host cache (LHC), and all data information is written to the database. Synchronize with the data stored in the database. This includes every login information for the user to the desktop, the disconnected session information will be written to the transaction log, rather than the IMA schema, not written to the database, but written to the local host cache inside.

write here, I think I need to add, what is the transaction log? SQL server Use the transaction log to store the modified database. This is a continuous database storage and modification of databases that are similar to data streams. In general our database file can be recovered from the transaction log if it is corrupted. In a highly available database solution, the high availability of database mirroring is maintained by the transaction log.

　　As a result, we generally understand the database Mirror Why is the database log so big and understand why XenApp of the Mirror No XenDesktop of the Mirror that's why the transaction log is so big. are based on the reason for their architectural design.

This article is from "I take fleeting chaos" blog, please be sure to keep this source http://tasnrh.blog.51cto.com/4141731/1435183