Tech Blog

Virtualization - Cloud

Page 5 of 8

Difference Between Always On Failover Cluster, Database Mirroring, Always On Availability Group, Replication and Log Shipping

December 31, 2019 /

I wanted to write this article to make it easier for you to choose between SQL Server’s technologies used for HA (High Availability) and DR (Disaster Recovery) for Citrix Virtual Apps & Desktop Site Setup

Briefly, we will compare the technologies listed below.

  • Always On Failover Cluster
  • Database Mirroring
  • Always ON Availability Group
  • Replication
  • Log Shipping

Always On Failover Cluster

  • You can use it for HA.
  • The servers to be included in the Failover Cluster must be in the same windows cluster.
  • Supports automatic failover. The failover process can occur automatically if the SQL Service stops.
  • There is no disk redundancy. Because, the database files use a shared disk that can be seen by both servers.
  • It can be done in Instance level (You cannot failover a database to the other server. All databases in that instance will failover. So it can not be practical for a DBA)
  • You can not read or write from the secondary databases.
  • It can be used with Always ON Availability Group, Replication, and Log Shipping.

Database Mirroring

  • You can use it as HA or DR solution. If you choose synchronous for nodes in same data center it can be HA Solution and if you choose asynchronous for nodes in different data centers it can be DR Solution.
  • Its database based. If you have too many databases, you need to do this for all the databases on the instance one by one. But it is more flexible because failover can be done on a database basis.
  • There is disk redundancy. Each node uses its own disks.
  • There is automatic failover if you set Witness Server and set it synchronously.
  • You can not read or write from the Secondary database. But you can read from the snapshot of the secondary database.
  • It will not be available in later versions of Microsoft SQL Server. Always On Availability Group can be used instead of Mirroring.
  • Supports automatic page repair. A nice feature for DBAs. Because this feature prevents the database from falling into suspect mode.

Always ON Availability Group

  • It can be used as HA or DR solution like Database Mirroring.
  • You can create an availability group by making a group of multiple databases. It is both more flexible and easier to manage than Database Mirroring. For example, an application has 7 databases. You can include these 7 databases into a single availability group. You can manage as you like. Availability Group is an improved version of Database Mirroring.
  • There is disk redundancy. Each node uses its own disk.
  • There is automatic failover if you set it synchronously. Does not need Witness server.
  • You can read from Secondary databases.
  • Supports automatic page repair. A nice feature for DBAs. Because this feature prevents the database from falling into suspect mode.
  • With SQL Server 2016, we can now create the Availability Group among different windows clusters.

Replication

  • Replication has many technologies and each offers different features. Therefore it is a little difficult to briefly describe Replication. For details, you should read the articles at the end of the article. Usually not used for HA. I’ve always used it for reporting purposes.

Log Shipping

  • Its a DR solution.
  • Its databases based.
  • You can read from secondary database.
  • There is no automatic failover.

My reasons to choose Always On Availability Group for HA:

  • It is very easy to manage Always On Availability Group.
  • You can include more than one database in an Availability Group.
  • You can use it for both HA and DR.
  • There is disk redundancy. You can read from the secondary database.
  • You can failover your availability group to the other server without anyone feeling the interruption.
  • Because you can group databases, you can get maximum benefit from their resources on 2 servers by running some of your availability groups from the first server and some from the second server.

XenApp/XenDesktop/Netscaler Gateway Communication Workflow

December 31, 2019 /

SSL Connection

This is the first step when user type the NetScaler Gateway vServer’s address into browser. We need to focus on the SSL handshake between client and server if any issue happens.

User-added image


Authentication

Commonly, customer uses LDAP domain authentication. In this article, I will use dual factor authentication as an example (LDAP+Radius).

User-added image

Get the App/Desktop List.

User-added image

 Get the ica file.

User-added image

ClienLaunch App/Desktop

User-added image

Ref: https://support.citrix.com/article/CTX227054

Hyper-V VM Integration Services: List of Build Numbers

October 23, 2017 /

Hyper-V integration services, are a bundled set of software which, when installed in the virtual machine improves integration between the host server and the virtual machine. Integration services (often called integration components), are services that allow the virtual machine to communicate with the Hyper-V host. Hyper-V Integration Services is a suite of utilities in Microsoft Hyper-V, designed to enhance the performance of a virtual machine’s guest operating system.

In short and general, the integration services are a set of drivers so that the virtual machine can make use of the synthetic devices provisioned to the VM by Hyper-V.

Hyper-V Integration Services optimizes the drivers of the virtual environments to provide end users with the best possible user experience. The suite improves virtual machine management by replacing generic operating system driver files for the mouse, keyboard, video, network and SCSI controller components. It also synchronizes time between the guests and host operating systems and can provide file interoperability and a heartbeat.

Below is the list of Integration Services Version numbers

Windows Server 2008

Build Number Knowledge Base Article ID Comment
6.0.6001.17101 n/a Windows Server 2008 RTM
6.0.6001.18016 KB950050 Windows Server 2008 RTM + KB950050
6.0.6001.22258 KB956710 Windows Server 2008 RTM + KB956710
6.0.6001.22352 KB959962 Windows Server 2008 RTM + KB959962
6.0.6002.18005 KB948465 Windows Server 2008 Service Pack 2
6.0.6002.22233 KB975925 Windows Server 2008 RTM + KB975925

Windows Server 2008 R2

Build Number Knowledge Base Article ID Comment
6.1.7600.16385 n/a Windows Server 2008 R2 RTM
6.1.7600.20542 KB975354 Windows Server 2008 R2 RTM + KB975354
6.1.7600.20683 KB981836 Windows Server 2008 R2 RTM + KB981836
6.1.7600.20778 KB2223005 Windows Server 2008 R2 RTM + KB2223005
6.1.7601.16562 n/a Windows Server 2008 R2 Service Pack 1 Beta
6.1.7601.17105 n/a Windows Server 2008 R2 Service Pack 1 RC
6.1.7601.17514 KB976932 Windows Server 2008 R2 Service Pack 1 RTM

Windows Server 2012

Build Number Knowledge Base Article ID Comment
6.2.9200.16384 n/a Windows Server 2012 RTM
6.2.9200.16433 KB2770917 Windows Server 2012 RTM + KB2770917
6.2.9200.20655 KB2823956 Windows Server 2012 RTM + KB2823956
6.2.9200.21885  KB3161609 June 2016 update rollup for Windows Server 2012

Windows Server 2012 R2

Build Number Knowledge Base Article ID Comment
6.3.9600.16384 n/a Windows Server 2012 R2 RTM
6.3.9600.17415  Windows Server 2012 R2 RTM + KB3000850
6.3.9600.17831 KB3063283 Windows Server 2012 R2 RTM + KB3063283
6.3.9600.18080 KB3063109 Windows Server 2012 R2 RTM + KB3063109
6.3.9600.18339  KB3161606 June 2016 update rollup for Windows Server 2012 R2 
6.3.9600.18398  KB3172614 July 2016 update rollup for Windows Server 2012 R2
6.3.9600.18692 June 27, 2017—KB4022720 (Preview of Monthly Rollup)

 

 

Hyper-V BIN file removal to retain storage space

August 14, 2017 /

The files used by Hyper-V VM are as below: In short, to explain:

  • .XML : This file  contain VM configuration details
  • .VHD and .VHDX: These files are virtual disks that hold the current virtual disk data, including partitions and file systems.
  • .BIN : This file contains the memory of a virtual machine or snapshot that is in a saved state
  • .VSV: This file contains VM’s saved state.
  • .AVHD and .AVHDX: These files are differencing virtual disks, commonly used for snapshots and Hyper-V checkpoints

The BIN file created in the virtual machine folder of the virtual machine is equal to the size of the memory of the virtual machine and is a placeholder to save the virtual machine state in the event that the Hyper-V host shut down.

The BIN file contains the memory of a VM and is located inside the GUID folder. If the VM in powered off state, there will be no BIN file present. This file is the equal to the size of the VM’s memory provisioning in Hyper-V Manger.

In Windows Server 2008 and Windows Server 2008 R2 – starting a virtual machine would result in Hyper-V creating a .BIN file which matched the size of the memory assigned to the virtual machine.  Microsoft did this to ensure that we always had enough disk space available to create a saved state (which is particularly critical if the physical computer is shutting down – and the virtual machine is configure to save state when the physical computer shuts down).

The BIN file is simply idle while the virtual machine is powered on; it is pre-allocated so that its space is guaranteed to be available if needed and for quicker response to a save action. However – many people did not like to see their disk space being “wasted” like this.., as BIN file is idle during running state.

To address this, since Windows “2012” Microsoft made a simple change: Hyper-V only pre-create the .BIN file if you choose “Save the virtual machine state” as the Automatic Stop Action for the virtual machine.  If you choose “Turn off the virtual machine or Shut down the guest operating system”, BIN file will not create with equal size of RAM.

It is still possible to save the state manually as long as there is enough room for the file. Above Automatic Stop Action setting in only applicable when Physical computer shutdown.

By default, all virtual machines have an Automatic Stop Action of Save, which means the state of the virtual machine saved to disk. However, the best practice is once Integration Services are enabled the Automatic Stop Action should be changed to “Shut down the guest operating system”, which performs a clean shutdown and no longer needs the BIN file to save the memory content to.

 Considerations:

  • Keeping BIN file is not recommended in a cluster environment as VM’s were configured in High Availability, in case of Physical computer shutdown, VM will failover to another anode hence there is no advantage of keeping BIN file.
  • Consider choosing BIN file if Hyper-v Servers are not in cluster (standalone) and no constraints with storage space.
  • VM move into saved state only when Hyper-v Host is gracefully shutdown and VM will not move to save state in case Hyper-v host is unexpected shutdown/restart.
  • Microsoft do not recommends keeping VM in saved state for the applications like Domain Controllers, Database, etc. Hence, change Automatic Stop Action to “Shut down” from “Save state” as per MS recommendations

 Steps to save storage space by removing BIN File

  • VM need to be powered off
  • Go to VM Settings ->Automatic Stop Action -> Change the Option from “Save the virtual Machine state” to “Shut down the guest operating system”
  • Power on VM
  • Execute similar steps for each VM4

Note:
Above feature succesfully implemented at  multiple customer environments which intern benefied customerin reclaiming Terabyte storage space

 

 

 

 

Local Host Cache Reintroduction– Long Awaited Feature

August 14, 2017 /

Local Host Cache (LHC) & Evolution

Local Host Cache was a core feature of the Independent Management Architecture (IMA) that was introduced with Citrix Metaframe XP 1.0 in 2001, and was still used until Citrix XenApp 6.5 and now reintroduced in XenApp/Desktop 7.12

Technically, the LHC is a simple Access database where it stores a subset of the data store in each Presentation (XenApp) server. The IMA service running on each Presentation(XenApp) Server downloads the information for every 30 mins or whenever a configuration change is made in farm.

LHC primary functions are permits a server to function in the absence of a connection to the data store & improves performance by caching information of applications.

LHC contain the information of servers, published applications, Domain & Licensing. LHC evolved a lot over the years and allowed SQL downtimes for an indefinite period in its last release with XenApp 6.5.

If the data store is unreachable, the LHC contains enough information about the farm to allow normal operations for an indefinite period, if necessary. However, no new static information can be published, or added to the farm, until the farm data store is reachable and operational again.

The disappearance of LHC

With the release of the awful version 7.0 of XenApp in 2013 and the move to XenDesktop FlexCast Management Architecture (FMA), Citrix decided to remove the Local Host Cache feature–and many others–without offering any other alternative. To be fair, Citrix converged XenApp into XenDesktop, which was already using the FMA design since the version 5 and without Local Cache Host equivalent.  This decision immediately made the SQL infrastructure a critical piece of any XenApp implementation. Any downtime on the SQL infrastructure would immediately cause a downtime for new sessions on the XenApp infrastructure as well. It could also have some side effects with the old Citrix Web Interface.

Citrix recommends having a highly available SQL infrastructure to host XenApp and XenDesktop databases. While you can successfully implement HA for your SQL infrastructure, it does not necessarily mean that you will avoid downtimes, as many components are to be considered.

The pseudo rebirth of LHC with Connection Leasing (CL)

Facing a storm of complaints, Citrix also started–finally!–to listen to its customers and released XenDesktop 7.6 in Sept 2014 with the Connection Leasing (CL) feature enabled by default.

Unfortunately, CL was not full replacement of LHC and it is alternative option provided in placement of LHC, limited to frequently used and assigned applications/desktops (up to 2 weeks by default). For users not using Citrix frequently or using pooled desktops, CL is completely useless and did not resolve anything. There are also many limitations: load management, workspace control, power actions are not supported.

The reintroduction of LHC

Citrix came up with a milestone achievement with its new idea as part of the XenDesktop 7.12 release in Dec 2016. This time, they claimed to bring back all the Local Host Cache (LHC) features from XenApp 6.5, even adding few improvements to make it more reliable. LHC feature is offered for Cloud and On Premises implementations along Connection Leasing in 7.12, but is considered the primary mechanism to allow connection-brokering operations when database connectivity to the site database is disrupted. Surprisingly, Local Host Cache feature is disabled by default. Let us expect Citrix to enable that feature by default in the next version.

When installing XenDesktop 7.12 and up, a SQL Express instance(Local DB) will be installed locally on each Delivery Controller to store the Local Host Cache. Config Synchronizer Service (CSS) takes care of the synchronization between the remote database and the Local Host Cache (Local DB). The Secondary Brokering Service (Citrix High Availability Service) takes over from the Principal Broker when an outage is detected and does all registration and brokering operations.

There are many limitations to consider with this version of LHC

  • Local DB, which is a runtime version of SQL Server with a specific licensing that limits the usage of four cores.
  • No support for Pooled desktops, which is a huge downside.
  • No change can be made to the farm (assignments, publications, power actions, etc.), you cannot even open the consoles (Director & Studio) and PowerShell
  • No control over the LHC election process and only a single Delivery Controller will take care of all VDA registrations and broker sessions for the whole zone during an outage which limits  5,000 VDAs per zone (not enforced)
  • Most importantly, it is only a one-way communication between the LHC and the remote SQL database
  • New version of the Local Host Cache would not assure you zero downtime. There is also a delay before users can actually connect .When the remote database goes down, VDAs still have to re-register to the newly and ONLY elected Delivered Controller. It can result in users not having icons in StoreFront or users not able to start new sessions for a short period.

In conclusion, it took Citrix almost 4 years to deliver a somewhat equivalent of the good old Local Host Cache for XenDesktop 7.x. The database is not a single point of failure anymore in a XenDesktop/XenApp deployment. However, customers with large deployments are not supported with this version of the Local Host Cache and some of the -HUGE- limitations can discourage you from using that feature

Ref:

 

PVS Streaming Service Abrupt Termination – Cache Change Mode Procedure for production vdisk

July 23, 2017 /

Issue:

PVS stream service abrupt termination  intermittently (approx. once in month) which causing user sessions freeze and user unable to launch HSD’s.

Environment :

2 Citrix PVS Servers (VM’s) with version 7.6
2000-3000 concurrent  Users
86 HSD’s & 6 Golden Images
Microsoft Hypervisor 2012R2 ( 15 Node) – CICSO UCS

Observations:

  • Issue occurring once or twice in a month and there is no common pattern in days or hours,issue recurring in both PVS servers at a time
  • No changes in environment
  • Onsite engineer informed that issue existed since 3 months and issue getting resolved post restart of PVS servers.
  • One day,  same issue repeated but issue not sorted out post restarting of PVS servers -> Issue escalated to support team (Me)
  • Observed  Event Id 11 :”Detected one or more hung threads , DbAccess error: <Record was not found> <-31754> (in ServerStatusSetDeviceCount() called from SSProtocolLogin.cpp:2903” -> Indicates “Thread hangs under the stream service” & DB Access errors
  • Observed multiple vDisk retries on the problematic target devices. 11 at boot time and approximately 611 per hour during session
  • Observed recommended MacAfee exclusions are not in place -> Stopped MacAfee service and restarted PVS server -> PVS Streaming service stable for some time on one PVS server  and again terminated ->Due to time constraint, logged a call with vendor(Citrix).
  • After 2 hrs, Citrix support joined the call and started collecting CDF races and procdump collection for the terminating stream service
  • After few hours , issue resolved automatically and Citrix support unable to find root cause with collected logs
  • In 2 months , issue repeated 2 times and customer frustrated as root cause was not found for abrupt streaming service termination intermittently.
  • Support Team (Myself) analyzed the environment and observed the Cache mode is configured as “ Cache on Server”  which is not recommended for Production environment , Best practice to use “Cache on RAM overflow to HDD”  which is a best practice to reduce load on PVS server & optimal performance ->Taken the same observation Citrix support and requested their observations

Explained to customer that missing of best practices will lead to these type of intermittent issues , since  there is no root cause found  and it is not a best practice to keep cache on server in production environment , prepared a plan to change cache configuration to” Cache on RAM overflow to HDD”.

Current PVS Storage configuration for cache as below

PVS1 (VM)->1700 GB allocated  through Virtual HBA ( Total golden Image Sizes is 440 Gb & Remaining for Write Cache)

PVS2 (VM) -> 1700 GB allocated through Virtual HBA ( Total golden Image Sizes is 440 Gb & Remaining for Write Cache)

Proposed Storage change Configuration as below:

Post referring multiple blogs, Write Cache proposed to all images(profiles) is 20 GB -> Therefore , for 86 HSD, 1820 GB required and it should present to complete Hyper-v cluster as HSD hosted on cluster.

Citrix-XenApp-XenDesktop-XenServer Servicing Options

July 16, 2017 /

Citrix provides servicing options to give greater flexibility and choice in how to adopt new XenApp, XenDesktop, and XenServer functionality while giving greater predictability for maintaining and managing the support of your environment

Last year, Citrix introduced two new XenApp / XenDesktop servicing options, the LTSR, which stands for Long Term Service Release and the CR a.k.a. Current Release., In 2016, Citrix announced first LTSR of XenApp and XenDesktop 7.6 and in 2017 first LTSR for XenServer 7.1 that is available for download on Citrix.com.

What is LTSR?

As a benefit of Software Maintenance, Long Term Service Releases (LTSR) of XenApp ,XenDesktop,XenServer enable enterprises to retain a particular release for an extended period of time while receiving minor updates that provide fixes, typically void of new functionality. Long Term Service Releases (LTSR) is ideal for large enterprise production environments where you would prefer to retain the same base version for an extended period

A Long Term Service Release guarantees 5 years of mainstream support and an optional 5 years of extended support (needs to purchased separately). This includes cumulative updates every 4 to 6 months, a new LTSR version of XenApp / XenDesktop every 12 to 24 months and any potential (hot) fixes

A valid Software Maintenance (SM) contract is needed to make use of the LTSR or CR servicing option.

Ideal customer environment for a LTSR is for the customers who typically follow a 3-5 year version upgrade cycle

Long Term Service Releases will have a regular cadence of Cumulative Updates that will typically contain only fixes

What is Current Release?

Any new release of XenApp/XenDesktop/XenServer will be labeled a Current Release. With the CR servicing option you can always make use of (install) the most recent XenApp and/or XenDesktop versions including all the latest enhancements and additions that come with it.

Its release cycles are much shorter with a new version release being announced every three to nine months in general.

Citrix recommends that large enterprise customers have a combination of Current Release and Long Term Service Release environments.

Switching from a LTSR to a CR servicing, and vice versa, is always optional as well

All initial releases of XenApp/XenDesktop/XenServer will be a Current Release. There will likely be multiple Current Releases of a major XenApp/XenDesktop/XenServer version (i.e. 7.6, 7.6 FP1, 7.6 FP2, 7.6 FP3, 7.7, 7.8 ,7.9,7.11,7.13,7.14); however, there will likely only be one LTSR release of that version after that release is considered customer-tested and industry-proven (i.e. 7.6 FP3).

How will the customer know if their environment is Long Term Service Release compliant?

Citrix support and engineering have developed the LTSR Assistant tool which will scan your environment and compare your environment with the necessary LTSR components to determine if you are compliant. The tool provides a report that will outline the necessary updates to achieve compliance. The LTSR Assistant tool is available for download athttp://support.citrix.com/article/CTX209577.

Will a customer running an LTSR compliant environment be supported if they also have non- compliant components?

Citrix does not recommend mixing non-compliant components. For example, if a customer decides to implement Provisioning Services 7.7, which is not compliant with the current 7.6 LTSR environment and the customer has an issue with Provisioning Services 7.7 the customer may be asked to move to the latest Provisioning Services Current Release to receive public fixes

How often will Citrix release a Long Term Service Release of XenApp and XenDesktop or XenServer?

Citrix will release a Long Term Service Release of XenApp and XenDesktop or XenServer based on the number of features, implementations, customer support cases and general feedback. However, as very general guidance it can be expected that Citrix will release a new Long Term Service Release every 12-24 months; however, Citrix reserves the full rights to alter those timelines.

Is Citrix discontinuing the process of providing Hotfix Rollup Packs (HRP) for XenApp and XenDesktop?

With LTSR, Cumulative Updates will replace Hotfix Rollup Packs (HRP). Hotfix Rollup Packs (HRP) will still be made available for XenApp 6.5.

Will 7.6 LTSR support XenApp for Windows Server 2008 R2 for 10 years?

Windows Server 2008 R2 will not be eligible for extended support. Citrix will continue to monitor Windows 2008 R2 lifecycle dates for future determination of lifecycle milestones.

 

 

« Older posts Newer posts »

SSL Code

© 2024 Tech Blog

Theme by Anders Noren — Up ↑