Best Practice for Sync Between Primary and Failover

I'm not quite sure I understand what you're trying to do.

 

By "synch", are you referring to configsync'ing or failover? Are you saying that once the new servers are added to the active BIG-IP, that you'd like to new configuration to get synched to the standby unit before doing something else? Please clarify.

 

 

Configsync is a "semi" blocking call, meaning that iControl will wait for as long as it can for configsync status before returning, but will cause an exception if the wait is longer than the webserver's response timeout. Configsync from the CLI/GUI is also a blocking call. Due to the nature of configuration synchronization, this process can't be non-blocking since we need to know that every aspect of configsync is successful or not synchronously, before something else that depends on the configuration is performed.

 

 

Loc

Config sync'ing. I would like to have the two synched somehow. I know that there is a call from iControl that will do it. However, what I am working is transactional, so it must synch before moving on to another task if I am to use that mechanism for synchronization. If I waited for it or the timeout, that kind of latency would really make this service unusable. I suppose you have answered my question. I really need to find another way to synchronize. Can I use a cron job? Could I do it with a monitor?

 

 

Thanks in advance,

 

Justin

Although you can configure a cron job to run configsync in the background, in your transactional code elsewhere, you still won't have any feedback that the configsync process is successful or not (unless you don't care if the new configuration actually can load on the peer machine). As you may have known, configsync is an involved process in which configuration from the source box must be packaged up and transferred to the peer box, and the new configuration must be loaded successfully on the peer. If you have a large configuration set with 1000s of VSes, pools and servers..., this may take some time to finish. It's the reason configsync is not seen as something that is done on a regular basis. Even when new servers are added/removed from a LB pool, typically configsync should only be done when everything is stabilized. The CLI, GUI, and iControl all use the same mechanism to configsync, so your cron job (which will likely use a CLI command) will also take approx the same amount of time to finish.

 

 

In the next release of BIGIP, we'll have an auto-configsync feature, in which if enabled, configsync will be automatically done when it detects that something has changed.

 

 

Thanks,

 

Loc

First off, I realize the age of this topic, but I had to respond. This is indeed my first post on devcentral.

 

 

My question is in regards to the 'auto config sync' option on the new release. My concern is for administrators who make changes to the configuration quite frequently, and whether or not the automatic nature of this synchronization will account for that. For example, if I remove a server for 10 seconds from a pool, is the automatic sync going to kick off twice?

 

 

Thanks for the time,

 

 

Billy

The "auto-configsync" feature will not start configsync'ing right away when configuration changes. There's a timeout period for the last configuration change to become "stable" before this feature kicks in. This timeout will be a configurable parameter.

 

Regards,

 

Loc

I have an Automated F5 Draining solution that would drain our servers. When I wrote this I assumed there was only 1 F5. But now I've realized in production environment, we would have 2 F5(1 Active and 1 standby).

 

 

So I was trying to figure out how should I change my design.

 

 

I thought I'll always get both(active and passive) F5 APi's address.

 

- First figure out which one is active.

 

- Do all my operations in active F5

 

- Do a Synch operation

 

 

This's going to be my constructor;

 

public F5API(String loadBalancerAddress1, String loadBalancerAddress2, String userName, String password)

 

{

 

 

F5Interface.initialize(loadBalancerAddress1, userName, password);

 

if (F5nterface.SystemFailover.get_failover_state() == iControl.SystemFailoverFailoverState.FAILOVER_STATE_STANDBY)

 

{

 

F5interface.initialize(loadBalancerAddress2, username, password);

 

if (F5nterface.SystemFailover.get_failover_state() != iControl.SystemFailoverFailoverState.FAILOVER_STATE_ACTIVE)

 

{

 

throw new Exception("No active F5's found");

 

}

 

}

 

}

 

 

After I do my operations, how do I synch with StandBy F5?( How do I do it in c??) Or do we have "auto-configsync" right now and I don't have to do anything.

 

 

Thanks,

 

Eray

To force a ConfigSync operation from one unit to another, you'll want to use the synchronize_configuration() method in the System::ConfigSync interface.

enum System::ConfigSync::SyncMode {
  SYNCMODE_BASIC = 0, // Synchronizes only basic configuration, such as /config/bigip.conf.
  SYNCMODE_ALL = 1 // Synchronizes all common files in /config, 
all common files in /etc, all common BIG/db keys, 
and any other information deemed necessary for a complete system configuration.
}
System::ConfigSync::synchronize_configuration(
    in SyncMode sync_flag
);

The docs for the method are located here:

http://devcentral.f5.com/wiki/default.aspx/iControl/System__ConfigSync__synchronize_configuration.html

Click here

As for autosync, I'm not sure if that has been added yet.. Take a look at the System.High Availability settings in the BIG-IP GUI to see if there is an option for it on your platform.

-Joe

Thanks for your answer.

 

I've tried;

 

public void SynchNow()

 

{

 

if (this.F5Interface.SystemFailover.is_redundant())

 

{

 

this.F5Interface.SystemConfigSync.synchronize_configuration(

 

iControl.SystemConfigSyncSyncMode.CONFIGSYNC_ALL);

 

}

 

}

 

 

The problem is I am always getting a "timeout exception". First of all if I am only changing the state/availability of a pool member do I need to use;

 

SYNCMODE_BASIC or SYNCMODE_ALL? If I have to use SYNCMODE_ALL, do I need to change the Timeout variable?

 

Is synch operation "only" updating the difference between config files, or does it copy the whole config file?

 

 

Here's what I got If I go to High Availability->Config Sync;

 

 

ConfigSync Peer Use Primary Connection Mirror AddressSpecify IP Address...

 

ConfigSync Peer Address x.x.x.x

 

ConfigSync Peer Address

 

ConfigSync User Name: xxx

 

Password:

 

 

Encryption offon

 

Passphrase

 

Verify Passphrase

 

Detect ConfigSync Status Enabled

 

Status Message Local configuration and peer configuration have changed: Duplicate the changes, then perform ConfigSync

 

Last Change (Self) Wed Mar 12 06:59:48 PDT 2008

 

Last Change (Peer) Thu Mar 06 14:12:53 PST 2008

 

Last ConfigSync Tue Feb 19 14:10:05 PST 2008

 

 

Couple of questions here;

 

What does ""Local configuration and peer configuration have changed: Duplicate the changes, then perform ConfigSync " means?

 

Can I do a "Synch" operation only if I am a "ConfigSync User"?

 

 

Thanks,

 

Eray

 

 

Hi Eray,

 

 

SYNCMODE_BASIC should be fine if you haven't changed routing or default profiles (or a couple of other not-normally-modified items like self-ip).

 

 

The message you're getting indicates that both systems have changes since the last sync, and rather than try to figure out who wins, it wants you to manually duplicate the changes between the two...

 

Last Change (Self) Wed Mar 12 06:59:48 PDT 2008

 

Last Change (Peer) Thu Mar 06 14:12:53 PST 2008

 

Last ConfigSync Tue Feb 19 14:10:05 PST 2008

 

 

 

 

Note that the last change for both systems is more recent than the last configsync, so the system doesn't want to sync and lose any of your changes.

 

 

The timeout is a little questionable... Can you traceroute from one to the other?

 

And you should try setting the timeout value - I forget the default, but I try to always set it to something so I know what I'm dealing with.

 

 

I hope that helps!

 

Don.

We are also trying to synchronize a HA pair after adding updating pools and getting a timeout error on the sync. Any help is appreciated.

 

 

our code:

 

 

interfaces.getSystemConfigSync().synchronize_configuration(iControl.SystemConfigSyncSyncMode.CONFIGSYNC_BASIC);

 

 

the error:

 

 

Exception in thread "main" AxisFault

 

faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException

 

faultSubcode:

 

faultString: java.net.SocketTimeoutException: Read timed out

 

faultActor:

 

faultNode:

 

faultDetail:

 

{http://xml.apache.org/axis/}stackTrace:java.net.SocketTimeoutException: Read timed out

 

at java.net.SocketInputStream.socketRead0(Native Method)

 

at java.net.SocketInputStream.read(SocketInputStream.java:129)

 

at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)

 

at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)

 

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)

 

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)

 

at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)

 

at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

 

at java.io.BufferedInputStream.read(BufferedInputStream.java:235)

 

at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)

 

at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)

 

at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)

 

at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)

 

at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)

 

at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)

 

at org.apache.axis.client.Call.invokeEngine(Call.java:2784)

 

at org.apache.axis.client.Call.invoke(Call.java:2767)

 

at org.apache.axis.client.Call.invoke(Call.java:2443)

 

at org.apache.axis.client.Call.invoke(Call.java:2366)

 

at org.apache.axis.client.Call.invoke(Call.java:1812)

 

at iControl.SystemConfigSyncBindingStub.synchronize_configuration(SystemConfigSyncBindingStub.java:913)

 

at iControlSandbox.main(iControlSandbox.java:35)

 

 

{http://xml.apache.org/axis/}hostname:COMPANY-E01F5F

 

 

java.net.SocketTimeoutException: Read timed out

 

at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)

 

at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:154)

 

at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)

 

at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)

 

at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)

 

at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)

 

at org.apache.axis.client.Call.invokeEngine(Call.java:2784)

 

at org.apache.axis.client.Call.invoke(Call.java:2767)

 

at org.apache.axis.client.Call.invoke(Call.java:2443)

 

at org.apache.axis.client.Call.invoke(Call.java:2366)

 

at org.apache.axis.client.Call.invoke(Call.java:1812)

 

at iControl.SystemConfigSyncBindingStub.synchronize_configuration(SystemConfigSyncBindingStub.java:913)

 

at iControlSandbox.main(iControlSandbox.java:35)

 

Caused by: java.net.SocketTimeoutException: Read timed out

 

at java.net.SocketInputStream.socketRead0(Native Method)

 

at java.net.SocketInputStream.read(SocketInputStream.java:129)

 

at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)

 

at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)

 

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)

 

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)

 

at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)

 

at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

 

at java.io.BufferedInputStream.read(BufferedInputStream.java:235)

 

at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)

 

at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)

 

... 11 more