We have a machine with multiple MQ clusters and listeners defined. Is there any script which can be used to create an exact replica on another machine. Are there any commands/tools available?
Our platform is Windows.
Backing up a QMgr to restore else where entails the following:
Back up object definitions. WMQ v7.1 has the dmpmqcfg command for this. Prior versions use SupportPac MS03, a.k.a saveqmgr.
Back up authorizations. Same options as previous bullet.
Back up the .ini files
Back up any exits and their parameter files
Note that the best practice is to restore these objects into a QMgr with a different name. There are issues in trying to keep the QMgr name identical, especially if you have clusters or use a commercial certificate authority to sign SSL certs.
The index of SupportPacs is here. There are many which can help with scripting and deployment but MS03 is my personal favorite for this task.
Related
According to Jelastic documentation it is possible to export the Environment configuration and download it so it can be restored in another provider
However I have tried with 2 Jelastic providers and they both have disabled the option for exporting private data.
So exporting/download/upload/import of environment is not possible.
i.e. I was expecting to have a process similar to CPanel backup/restore tool
In fact, another view for the deployment process gives a possibility to get rid of the model of handling the data or configuration on the platform. Try to think a bit differently and using CI/CD approach. The Jelastic provides a platform where something you created, locate on somewhere you're elaborating(VCS or GIT as an example) and based on or depends on the specific stack, already pre-configured like a layer and can be installed(copied) over Jelastic. Don't need to handle the data somewhere in the cloud because you have it locally(means within any VCS) and doing the changes there. Then just do a 'pull' procedure(manually or automatically) on that deployment(test, production, staging) environment you're expecting.
Moreover, you can expect any environments type like a code and perform it creating before deploying the data.
Please, find the articles being described each case:
Deployment Guide
Jelastic Packaging Standard for CI/CD Automation
In case you would like to handle the databases' backups, check this article:
Scheduling Database Backups
Additional FTP add-on can make the copies more easily for each instance:
FTP/FTPS Support in Jelastic
What creates the profiles under {install_dir}/IBM/WebSphere/Appserver/profiles
I'm working on RHEL. Installed WAS 7 and WebSphere Commerce. All of this is scripted given to me by others.
At some point a folder gets created under profiles. However, I must have done something to mess this up, because on subsequent attempts to repeat this on new servers the folder doesn't get created.
WebSphere application server profiles are created and managed either using IBM Profile Management Tool (PMT) GUI or the command line version, manageProfiles in the bin dir. More general infomation about profiles can be found in this IBM KnowledgeCenter topic.
Found the answer. This is WAS meets Commerce. So the WAS "profile" gets created when Commerce creates what it calls an "instance". On my system, this is performed within the script:
{scripts}/IBM_WCS/instance_Creation.sh
Whether that comes from the vendor or is an invention of my predecessor, I have no idea. But once I got that to run, the profile appeared.
At a customer they are thinking to replace their local WAS Server as development sever by the lightweight WLP.
They make use of car files to deploy configurations to new Websphere server or reinstall a was server.
Is it possible to use these car files also on WLP? Or is there another way to ship was configuration between servers.
The existing CAR archives won't be usable, but there are (what I would describe as) superior ways with Liberty.
Liberty:
uses more human editable configuration to begin with
allows you to include xml snippets directly without an intermediate representation twlp_setup_includes.html
allows the entire server + config + applications to be packaged up and relocated (see the "server package" command for details) twlp_setup_package_server
I've installed WebSphere Application Server Network Deployment and need to run three different applications.
For each (Standalone) Application Profile creation I come across these options
Node Name, Server Name & Host name.
When first profile is created the values are
Node name - iamNode01
Server name - server1
Host name - iam
Second profile has following values auto-populated
Node name - iamNode02
Server name - server1
Host name - iam
etc..
If any one could help me understand on Node name and server name part.
There are two types of profile, you can have a single server/standalone profile, or one that is part of a cell and managed by a deployment manager. If you are using standalone profiles I would recommend having one server per profile. If you are using a deployment manager managed profile then you can have multiple servers per profile.
When an ND installation spans more than one machine, each machine has to be a different node. You can have multiple nodes on a single machine too if you like.
If there's a deployment manager in use, the simplest single machine setup is two profiles, one with the deployment manager in it and the other with all the appservers in it.
If there's no deployment manager (a standalone profile), then the simplest thing is one appserver per profile, and each profile will have it's own nodename.
Node name usually identifies logical node, in case of distributed installations (the ones with deployment manager), it helps you identify machine where servers are installed.
In case of standalone profiles, it is just hostname with Node0# appended.
If you want to have multiple standalone profiles on one machine, you can consider creating AdminAgent profile and register standalone profiles there. It will allow you to administer all servers from one console, just selecting specific profile on login.
You could create many servers on single standalone profile, however it is only possible via wsadmin and in general not recommended.
Server name identifies specific JVM, it must be unique on given node.
Maybe an element you are missing here is that Standalone profiles are not coordinated by a deployment manager nor node agent, so they are each just acting as if they are the a singler server on a single node -- hence the apparent duplication/multiple nodes per host.
You wouldn't have this relationship in federated (non-standalone) profiles -- just 1 managed node per operating system instance.
Situation
Oracle APEX (version not specified)
Single Application
Administration Issue: Deployment of New App version.
Detail
The latest version is on Server1
End Users are actively working on an older version hosted on Server2.
How do I import the changes made on Server1 without impacting users who may still be working on Server2?
Some Basics on Deploying APEX App Upgrades
It's always good etiquette to warn users that an upgrade will be in progress. Give a few days advanced notice and a window of time you will need to accomplish the task. In this case, as I will explain, you can install your new upgrade and switch over to the new version quickly.
Use an Application Alias
Use an Application ALIAS to identify your application to get away from the arbitrary, sequence controlled ID.
This is where to identify an APP ALIAS
In this example, the Alias AND the ID can be used. I recommend to publish the ALIAS to the users and the support staff who make the little shortcut icons on everyone's desktop:
http://sakura.apex-server-01.guru:8080/apex/f?p=ALIAS
Where "ALIAS" is whatever you've assigned to the app (such as 'F_40788'). Aliases must be unique across an entire INSTANCE, or you can set up some clever redirects using Oracle's RESTful Web Service builder.
How to Switch Your Live Application to Maintenance Mode
The best way to avoid any unwanted DML or user activity from end users is to lock the front-end application right before you switch over to the new version.
This will prevent anything from changing the state of the data during the upgrade... in answer to the question, if a DML (insert, update, delete) activity initiates when the app is overwritten, either the transaction fails and rolls back because it didn't reach the COMMIT step.. or worse. You're better off just locking up for a few minutes.
How to Set an Application to Maintenance Mode
Rename your current version to the permanent ALIAS and archiving the one it replaced. It's better not to overwrite or immediately delete your older versions.
Multiple Versions Co-existing in the same Workspace:
It is equally as useful to check in the exported application definition scripts as they are encoded in UTF-8 plain text SQL. The benefit is that source code diffs can identify the differences between ver
As long as their access is restricted, and their alias changed to a unlisted value, they serve as a good fallback for any unanticipated issues with the new, current release.