Z

azwyczaj dla wewnętrznych aplikacji – do uzyskania stałego przypisania IP klienta do puli adresów obsługujących żądania wybieraliśmy profil source_addr z ustawionym czasem wygaśnięcia np. na 3600 sekund. Problem z tego typu rozwiązaniem jest taki, że po wygaśnięciu czasu utrzymania informacji o przypisaniu klienta do wybranego serwera backend’u traciliśmy gwarancję, że zostanie on ponownie przypisany do tego serwera.

Przykład – pierwsze żądanie klienta trafia do 1’ego serwera w puli:

root@server1:~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

10.64.36.240 - - [02/Mar/2016 16:11:52] "GET / HTTP/1.1" 200 -

Po przeminięciu czasu wygaśnięcia (1h) ten sam klient trafia już do 2’ego serwera w puli:

root@server2:~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

10.64.36.240 - - [02/Mar/2016 17:18:29] "GET / HTTP/1.1" 200 -

Bardzo często powodowało to problem z dwoma aplikacjami, które wystawiały sobie poświadczenia bezpieczeństwa na podstawie adresów źródłowych, lub aplikacjami, które musiały przechowywać i odczytywać dane z tych samych źródeł przy zachowaniu wysokiej dostępności (komunikacji przez VIP). Od wersji 10.0.0 z pomocą przychodzi algorytm CARP (ang. Cache Array Routing Protocol), który jest pozbawiony potrzeby przetrzymywania wpisów łączących klientów z serwerami oraz potrafi zapewnić automatyczną redystrybucję żądań klientów, które skierowane były do aktualnie niedostępnego serwera.

W celu włączenia CARP dla Source Address Affinity wystarczy podczas tworzenia trwałego profilu (Profiles -> Persistence) wybrać w polu Hash Algorithm wartość “CARP” zamiast “Default“. Tak zapisany profil później należy wybrać w polu “Default Persistence Profile” zakładki “Resources” wybranego Virtual Server’a.

Więcej informacji: SOL11362: Overview of the CARP hash algorithm