Monday Feb 28, 2011

GlassFish 3.1: Automatic Domain Backup

In a prior post I wrote about the commands we reintroduced in GlassFish 3.1 which allows administrators to manually backup and restore a GlassFish domain.    There is more to it than that.   We also introduced support for scheduled automatic backups of a domain.   This new feature is only available in Oracle GlassFish Server.   For those who are not familiar with Oracle GlassFish Server this is our commercial distribution of the GlassFish Server Open Source Edition. Oracle GlassFish Server is backed by support from Oracle and is distributed with GlassFish Server Control which is a collection of additional features which enhance the functionality of Oracle GlassFish Server.

Here is a short summary of how it works.    It is pretty simple.   You basically create a new object called a Backup Configuration (this named object describes the type of backup you want to perform).   You associate the Backup Configuration with a named Schedule.    Multiple Backup Configurations can exists (some enabled, some not) and they can point to the same schedule or different schedules.

The Backup Config has the following attributes:

  • Name
  • Schedule
  • Enabled (Boolean)
  • Backup Location
  • Recycle Limit
  • Live Backup (Boolean)
  • Backup Type (Full or Config Only)

The Name is the name of the Backup Configuration and you can create as many of these as you like.   Each Backup Configuration must be associated with an existing schedule.    The product ships with three pre-defined schedules: daily, weekly and monthly but you can create more or modify the existing schedules.  A Backup Configuration is enabled by default but you can change the Enabled attribute to temporarily turn off a scheduled backup.   If you do not specify a backup location the backups (in the form of zip files) are maintained in the domain directory (backups subdirectory).    The recycle limit allows you to control the number of prior backups to maintain.   The default is 25.   When that number is reached older backups are deleted as new ones are added.     The live backup option allows the backup to be performed on the DAS without suspending it (more on that in a future posting).    Finally you can control whether a full backup is performed, which is the entire domain directory (sans existing backup files), or just the domain's configuration.

A good practice might be to perform a full backup of the domain once or twice a month and perform configuration only backups daily.

Here's a quick example using the asadmin CLI to create these two automatic backups.   You can also perform the same operation using the GlassFish Console which I will demonstrate in a different blog entry.

First I'll list the existing schedules:

% asadmin list-schedules --long
NAME           SECOND  MINUTE  HOUR  DAY OF WEEK  DAY OF MONTH  MONTH  YEAR  
daily          0       0       0     \*            \*             \*      \*     
weekly         0       0       0     Sun          \*             \*      \*     
monthly        0       0       0     \*            1             \*      \* 
Command list-schedules executed successfully.

So as you can see there are three existing schedules.    The daily schedule defines an event which occurs every day at midnight.  The weekly defines an event to occur every Sunday at midnight and the monthly schedule defines an event to occur on the first day of the month also at midnight. 

I'll create a new backup config to perform our monthly full backup of the domain directory:

% asadmin create-backup-config --schedule monthly --backupdir /tmp/das-backups --recyclelimit 12 d1-full
Command create-backup-config executed successfully.
 

The above command creates a backup config which is associated with the monthly schedule.  The backups which are created are stored in /tmp/das-backups and I'm using the recyclelimt option to control the number of backups I will maintain (twelve in this case).

The next command:

     % asadmin create-backup-config --schedule daily --backupdir /tmp/das-backups --recyclelimit 30 --configonly d1-config 
     Command create-backup-config executed successfully
 

creates another backup config which kicks off a backup daily.   This backup config will only backup the contents of the config directory for the domain.    Since this backup config is associated with the daily schedule the backup will occur every day.

It is worth noting that multiple backup configs can reference the same schedule.    They will both get executed at the same time although the order in which they will be executed is not defined.

If you want to see the details of a specific backup config you can use the new list-backup-configs subcommand:

% asadmin list-backup-configs --long d1-config
Name of Backup Config   :d1-config
Auto Backup Enabled     :true
Schedule                :daily
Recycle Limit           :30
Config Only backup      :true
Active Backup Enabled   :false
Backup Directory        :/tmp/das-backups
Last Backup Attempt     :Mon Feb 28 14:05:55 PST 2011
Last Successful Backup  :Mon Feb 28 14:05:55 PST 2011

Schedule Details:
NAME   SECOND  MINUTE  HOUR  DAY OF WEEK  DAY OF MONTH  MONTH  YEAR  
daily  0       0       0     \*            \*             \*      \*     
Command list-backup-configs executed successfully.
 

The backups will be performed as long as the Domain Administration Server (DAS) is running. When the event is scheduled to occur the DAS will suspend the domain temporarily.   When the domain is suspended any command which would cause the DAS to modify the domain directory is blocked (other commands such as list-clusters are allowed).   This allows the backup to be safely performed.   Once complete the DAS is resumed so that all operations are allowed.

You can use the list-backups command to list available backups.   In this example I'll look at the backups available in the /tmp/backups directory:

% asadmin list-backups --backupdir /tmp/das-backups
CONFIG     USER   BACKUP DATE                   FILENAME                       
d1-config  kasso  Thu Feb 24 00:00:00 PST 2011  domain1_2011_02_24_v00005.zip  
d1-config  kasso  Fri Feb 25 00:00:00 PST 2011  domain1_2011_02_25_v00006.zip  
d1-config  kasso  Sat Feb 26 00:00:00 PST 2011  domain1_2011_02_26_v00007.zip  
d1-config  kasso  Sun Feb 27 00:00:00 PST 2011  domain1_2011_02_27_v00008.zip  
d1-config  kasso  Mon Feb 28 00:00:02 PST 2011  domain1_2011_02_28_v00009.zip  
d1-full    kasso  Wed Feb 23 10:49:47 PST 2011  domain1_2011_02_23_v00001.zip  
Command list-backups executed successfully.
 

If you wanted to restore the lastest backup of the domain you would stop the domain and then use the restore-domain command:

% asadmin stop-domain
Waiting for the domain to stop ......
Command stop-domain executed successfully.
% asadmin restore-domain --backupdir /tmp/das-backups --backupconfig d1-full domain1
Restored the domain (domain1) to /work/ogs/glassfish3/glassfish/domains/domain1
Command restore-domain executed successfully.
 

This replaces the contents of the domain directory with the contents of the full backup of the domain. For additional details about creating backup configurations and schedules see the Oracle GlassFish Server 3.1 Administration Guide.


Wednesday Feb 16, 2011

GlassFish 3.1: Backup and recovery commands have been restored

For those familiar with earlier versions of GlassFish you may recall a couple of commands that could be used to backup and restore the DAS:

  •  backup-domain
  •  restore-domain
  •  list-backups

While these commands were available in 2.x they did not make it into v3 or 3.0.1.   They are back in 3.1. 

The backup-domain command will create a zip file that contains the contents of the domains/<domain> directory.   This includes configuration and deployed applications.   This zip file could be used to restore the DAS, retrieve a prior configuration or migrate the DAS to a different system.

The restore-domain command reversed the behavior of backup-domain.   It essentially takes the zip file and restores it to the domain directory.   Pretty simple stuff.   Some details about how the prior versions of these commands worked is captured in the DAS Recovery One Pager.

In 3.1 we made some improvements over the prior implementation.   For example in 2.x the backup file name was called: sjsas_backup_vNNNNN.zip  where NNNNN is a number (e.g. 00001).  This number is incremented for each backup.   For 3.1 we have changed the backup name to domain_name_YYYY_MM_DD_NNNNN.zip. For example: domain1_2010_05_28_000001.zip.  This makes it easier to manage these files for those cases where you move them to an alternate location away from the domain directory.

Prior to 3.1 the backup would be stored in the domain directory where the backup was created.  It was not possible to specify an alternate location for the backup.   In 3.1 we have added a new --backupdir option to backup-domain so now it is trivial to store the backups outside of the domain directory:

    asadmin backup-domain --backupdir /net/backuphost/domain1 domain1
    Backed up domain1 at Wed Feb 16 15:13:46 PST 2011.
    Command backup-domain executed successfully.
  

The restore-domain command now allows you to restore to a domain where the name of the domain does not match the domain the backup originated from.    The default behavior is to not allow this to occur but the behavior can be overridden with the --force option.   If the --force option is used the domain name used to create the backup will be used.

Finally we also improved the output of the list-backups command:

    
    asadmin list-backups
    CONFIG  USER   BACKUP DATE                   FILENAME
            kasso  Wed Feb 16 15:22:18 PST 2011  domain1_2011_02_16_v00001.zip
            kasso  Wed Feb 16 15:22:20 PST 2011  domain1_2011_02_16_v00002.zip
            kasso  Wed Feb 16 15:22:22 PST 2011  domain1_2011_02_16_v00003.zip
            kasso  Wed Feb 16 15:23:06 PST 2011  domain1_2011_02_16_v00004.zip
    Command list-backups executed successfully.
   

With the --long option more details about the backup can be displayed:

    asadmin list-backups --long
    Description               : domain1 backup created on 2011_02_16 by user kasso
    GlassFish Version         : Oracle GlassFish Server 3.1 (build 43)
    Backup User               : kasso
    Backup Date               : Wed Feb 16 15:22:18 PST 2011
    Domain Name               : domain1
    Backup Type               : full
    Backup Config Name        :  
    Backup Filename (origin)  : /work/ogs/glassfish3/glassfish/domains/domain1/backups/domain1_2011_02_16_v00001.zip
    Domain Directory          : /work/ogs/glassfish3/glassfish/domains/domain1

The ability to create and managed domain backups for your DAS has been restored in the GlassFish Server Open Source Edition.   The commands with the new enhancements our available now in promoted builds of GlassFish 3.1.

Friday Apr 30, 2010

GlassFish Server Open Source Edition 3.1 Engineering Meeting

Our first engineering meeting for the GlassFish Server Open  Source Edition 3.1 release will be on Wednesday at 9AM PDT.

Meeting information is available on the GlassFish Wiki.  The meeting is open to all community members.

The primary drivers for this release are clustering, centralized admin and high availability support.

Tuesday Jun 09, 2009

Update Center: Updates Made Easier

The Update Center toolkit has already made applying updates to projects like GlassFish, MQ and Web Space Server easy.  With the release of Update Center 2.2 that process just got easier.

In prior releases the Update Tool GUI or the pkg(5) CLI were the primary mechanisms available to apply updates.  This had its limitations.  For example if a developer wished to update multiple applications, each need to be selected, "Available Updates" checked and then applied before repeating for the next application in the list. Easy enough if only one or two applications are being maintained.  More than that and the process becomes fairly heavyweight.

Enter Update Center 2.2.  In this release we have introduced a new streamlined update mechanism.   The new Software Update GUI can detect and apply updates simultaneously across multiple application images maintained on a system.  Applying updates is as easy as two mouse clicks (1. accept the license 2. click Install) to update the applications.

Here's a look at the new Software Update GUI:

Software Update GUI Image

How does it work?

The new Software Update GUI is typically started by clicking on the notification balloon generated by the Update Center desktop notifier. The tool checks for updates in the application images registered with the Update Tool.  Only those applications with pending updates are displayed. These applications will be preselected in the tool.  To apply the updates just accept the license and click Install.

The tool will then apply the updates in a serial fashion to each of the selected applications.  An install dialog tracks the progress:

Applying an update

Details of each update are available for review after the update completes.

There are a couple of other features of the tool worth mentioning.  If an application update contains security related fixes or enhancements they will be identified with the security emblem:



You can also select an application to view more details about the update:



The Software Update GUI is also connected to an atom feed that allows it to recommend featured add-on software that is applicable to the applications which are already installed.  Select the add-ons you wish to install and they will be included in the update process when you click Install.  If the add-on can be applied to more than one image you will be prompted to indicate which images to apply the add-on to.  Overall a fairly streamlined process.

The Update Tool is still available to provide finer grain control over which components in an application are updated.  To access the Update Tool simply click on the "Manage Details" button at the bottom of the tool.

Tuesday Apr 28, 2009

Java Enterprise System 6

The Java Enterprise System 6 (Java ES) product released yesterday.  The Java ES product is comprised of a suite of more than eight products which have been designed and tested to interoperate.  One of the primary goals of Java ES is to design products such that they share common system level characteristics.  These characteristics include such items as platform, browser and web container support to name just a few.

The common system level characteristics which Java ES products are expected to adopt are defined in a specification called the Software Infrastructure System Requirements Document (SRD).  The SRD is updated twice a year with input from engineering, marketing and the field.  It covers a range of topics which are applicable to most products.

The items in the SRD are presented as a set of requirements and informational items.  Products under development are expected to adopt a specific SRD version and implement the requirements of the SRD as part of their product release.  General areas the SRD covers include:

  • Platform support
  • Virtualization
  • Interoperability
  • Compilers
  • Java SE and EE
  • Browser support
  • Database requirements 
  • Installation and update requirements
  • Security
  • Branding and naming
  • Product life cycle

Many of the requirements establish a floor or minimum.  This allows product teams to do more than required in order to support their customer needs.

Prior to the existence of the SRD each product team would make their own decision about which browsers, databases and platforms they chose to support.   This lead to inconsistencies across products and made it difficult for customers to integrate products into a common solution.  The existence and adoption of the SRD aligns products on common requirements and thus eliminates integration issues that can hinder product adoption.

Friday Nov 21, 2008

Update Center: Desktop Notifier Start Up

In my  entry last month I discussed some ways to manage the Update Center's desktop notifier.   In the upcoming release  of version 2.1 of the Update Center project  the team added some additional mechanism to launch the notifier.  The most noticeable change is the update preferences accessed via the updateool GUI:

Preferences Dialog

The "Automatically check for updates" check box is used to indicate whether the notifier should be started automatically when  you log in to your desktop.    If this check box is selected when this dialog is applied the notifier will be registered  as a log in start up task.   The notifier will also be started immediately at that point.   If the notifier is already running the newly started notifier will silently exit.

If the "Automatically check for updates" check box is not selected when the dialog is applied the notifier will be unregistered as a log in start up task.   Any currently running notifier instances will be shutdown when the dialog is  dismissed.    By selecting or deselecting (and applying) the check box the current notifier operation can be controlled.

In UC 2.0 the updatetool GUI would automatically (as a background task) register the notifier shortly after it is started if the update check frequency is set to daily, weekly or monthly.   This still occurs in UC 2.1 (if the "Automatically check for updates" check box is selected).  New in version 2.1, the updatetool GUI will also start the notifier automatically shortly after the GUI is launched.  This instance of the notifier will silently exit if another instance of the notifier is already executing.

We also added the ability to stop the notifier from the command line:

% updatetool --notifier --shutdown

This command has no output.   It simply sends a message to the running notifier to shutdown.    This command is useful on Windows in the scenario where a user wishes to move or delete an application folder but is blocked because the running notifier instance was started from within the folder.   Windows will not allow a folder to be deleted if files within the folder are still in use.  

 Current builds of Update Center can be accessed through our download site:

http://wikis.sun.com/display/IpsBestPractices/Downloads

 These changes will appear in build 18.



Wednesday Oct 22, 2008

160.6 million shares and counting

This is interesting:

Value investment firm boosts stake in Sun Micro

   ``Memphis-based Southeastern said it has talked to Sun's management, and
      will have further discussions "regarding opportunities to maximize the
      value of the company for all shareholders."''

Hawkin's company has lost between $1 and $2 billion in their investment in GM over the past decade.  Hopefully they will do better with their  Sun ownership.

I think odds are he's going to stir things up a bit at Sun.  Probably not the same way Carl Icahn tried to at Yahoo but I suspect he will be a force in directing our future.  

If anything it provides pressure on the Board to fulfill their responsibility to the stockholders.   

Wednesday Oct 08, 2008

Update Center: Managing the Desktop Notifier

The Update Center desktop update notifier is a small application that resides in the system tray or task bar. It monitors registered application installations and package repositories periodically to see if any updates are available for the software installed by the user. When updates are available the notifier informs the user and subsequently allows the user to review and apply the updates.  You can see some of the screenshots for the notifier on the Update Center wiki

Generally the notifier is started when a user logs into their desktop. In order for the notifier to be started when a user logs in it must first be registered as a log in start up task.

There are a couple of paths that will result in a registered notifier. For example the GlassFish v3 Prelude installer allows the user to "Enable Update Tool".  By selecting this option the notifier will be registered and started as part of the GlassFish installation.  Here's an example of the GlassFish Update Configuration screen:




Some products may use the Update Center's bootstrap and stub scripts as a way to minimize the download size of the product as well as maintain platform neutral distributions .  When the user launches the updatetool bootstub (to install the actual Update Tool packages) it will register and start the notifier:

% updatetool

The software needed for this command (updatetool) is not installed.

If you choose to install Update Tool, your system will be automatically
configured to periodically check for software updates. If you would like
to configure the tool to not check for updates, you can override the
default behavior via the tool's Preferences facility.

When this tool interacts with package repositories, some system information
such as your system's IP address and operating system type and version
is sent to the repository server. For more information please see:

http://wiki.updatecenter.java.net/Wiki.jsp?page=UsageMetricsUC2

Once installation is complete you may re-run this command.

Would you like to install Update Tool now (y/n):

(package installation output deleted)

Registering notifier: Successful.
Starting notifier.
Initialization complete.

If the notifier was not registered during installation it can be registered post install.  The Update Tool GUI application will attempt to register and start the notifier (if it is not already registered and running) shortly after it is launched if the update check frequency preference is set to a value other than "Never".  You can check this preference via the Updates tab in the Update Tool Preferences dialog.

Finally the notifier can be started manually from the command line like this:

% updatetool --notifier

but only one instance of the notifier per user can be running simultaneously. So if the notifier was started as a log in start up task a second instance started manually might complain:

% updatetool --notifier
Update Tool Notifier: The tool is already running.

Is the Notifier Registered?

There is an easy way to determine if the notifier is registered as a start up task on your system.  Go to the directory where you installed Update Tool or Glassfish and navigate into the updatetool/bin directory.  The updatetoolconfig tool can be used to manage the notifier's registration.  To see if the notifier is already registered run updatetoolconfig like this:

% updatetoolconfig --list

If this doesn't display any output then the notifier is not registered.  The tool also returns an exit code of 1 if the notifier is not registered.

Registering/Unregistering the Notifier

You can also use the updatetoolconfig tool to manually register and unregister the notifier:

% updatetoolconfig --register

and

% updatetoolconfig --unregister

A couple of comments about these operations.  If a notifier is already registered then --register will not work.  To override the existing registration you can use the --register --force options.

If there are multiple installed product images that the notifier is monitoring on the system then a simple --unregister will not unregister the notifier.  The notifier can only be unregistered this way if there is only one monitored image remaining (more about this in a future blog entry).

To force the notifier to be unregistered when there are more than one installed product images on the system use the --force option along with --unregister.

You can alway verify the registration or unregistration was successful by using the --list option.

Registering the notifier with the updatetoolconfig tool will not cause the notifier to be started immediately.  You must log out and then log back in to trigger the start of the notifier.

Notifier Firewall Interaction

When the notifier is started it opens a port and listens for connections from the Update Tool.  If this is the first time the notifier is run it may trigger your firewall to display a security alert indicating that Python (the notifier is based on Python) is attempting to connect to the network.  You should allow this operation.


About

Chris Kasso

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today