N-Tiered application backups

[jboggon]

Hi All,
Am after some advice on backing up a JDE EnterpriseOne application deployed in an n-tiered architecture.

Virtualisation platform is VMWare. Operating systems are Windows Server 2008R2. the database is MS SQL Server

The database and logic layers are installed on a dedicated VM. The presentation layer is installed on a second, separate, dedicated VM. The deployment layer is installed on a third dedicated VM. This architecture is duplicated to provide a development and test environment, so there are six VM's in total.

The application administrators have requested that some backups of the application be done cold (IE with all the VM's powered off)- they are concerned with preserving the state of the application as a whole, rather than just "per server". They want these backups done before and after major milestones.

I have a couple of concerns.
1) If the "state" of an n-tiered application crosses multiple VM's, what does this mean for the normal scheduled "hot" backups where the running VM's are backed up sequentially?
2) How does this affect Disaster Recovery? We currently have a replication job that copies the data to a remote site. Are these replicas viable?

Has anyone else have any experience with this they could share?

John.

[PTide]

Hi John!

Could you please provide more info about your app? I am aware of a Presentation-Logic-Data three-tier model, whereas you've mentioned the "deployment tier". What role does this tier play in your app?

Thank you.

[Vitaliy S.]

Hi,

1. This means that all VMs will be backed up one by one (depending on your parallel processing tasks option). If you want to have a consistent state of your application, we do recommend to enable application-aware image processing, which triggers VSS writers inside the VM. BTW, what's the name of the application you use?
2. Yes, they are. If you need, you can confirm that via SureBackup jobs and see if application you replicate can be used in the DR situation or not.

Thanks!

[jboggon]

Hi John!

Could you please provide more info about your app? I am aware of a Presentation-Logic-Data three-tier model, whereas you've mentioned the "deployment tier". What role does this tier play in your app?

Thank you.

Sorry PTide, my description was not quite as accurate as it should have been.

Deployment is not a layer or tier. It's a sub-application that packages and pushes out updates and changes to the rest of the EnterpriseOne application. It runs on a separate VM to the DB/logic and presentation layers.

[jboggon]

Hi,

1. This means that all VMs will be backed up one by one (depending on your parallel processing tasks option). If you want to have a consistent state of your application, we do recommend to enable application-aware image processing, which triggers VSS writers inside the VM. BTW, what's the name of the application you use?
2. Yes, they are. If you need, you can confirm that via SureBackup jobs and see if application you replicate can be used in the DR situation or not.

Thanks!

Vitaliy,
The application is JD Edwards EnterpriseOne. It's an integrated suite of ERP applications.

All the servers do have Application Aware processing enabled, but the Administrators concern is that the state of the E1 application is not completely contained on a single VM. For example, the deployment VM could conceivably be pushing out an update to the business logic layer - if the deployment VM is not backed up at exactly the same time as the BL VM, then the state of that deployment on the backed up VM's will not be consistent.

[PTide]

John,

Deployment is not a layer or tier. It's a sub-application that packages and pushes out updates and changes to the rest of the EnterpriseOne application. It runs on a separate VM to the DB/logic and presentation layers.

I've just depictured it in the following way:

- Presentation layer VM provides end users with some kind of interface to interact with, so even if you shut down the entire presentation-VM nothing severe will happen to app, is that correct?

- DB/logic VM does all sorts of data processing (updates, inserts, selects) and get orders from presentation layer. Is that correct?

- Deployment VM manages the updates and changes of the whole Application but does not ever touch the data which is being manipulated by DB/logic VM. Is that correct?

[Vitaliy S.]

Hi John,

Yes, when using VM snapshots VSS preparation time can vary from one VM to another, so even if you snapshot VMs at the same time, VSS process will take different time on different VMs (depending on how busy VM is). If your administrator is concerned about consistency across all VMs, then SureBackup jobs should be a way to go.

Thanks!

[PTide]

Hi John,

Any news? The reason why I've asked all of the things above is that I wanted to suggest you to use the pre-job- and after-job-script features of VBR in order to temporarily freeze all app-related interactions between your servers gracefully from the inside. That would allow you to be sure that none of them

"could conceivably be pushing out an update to the business logic layer"

or something.

[jboggon]

No news yet - the application vendor has gone suspiciously quiet.

That's a great idea though. I will put it to the vendor.

[PTide]

If you decide to test it, then please give us some feedback about the results!

Thank you.