Entendo que a versão do rampartc é 1.3.0, enquanto a versão atual do axis2c é 1.6.0. Então é a versão atual.
Nós não vimos esse problema na sincronização: se os tempos estão dentro de 5 minutos, normalmente funciona.
Estou com problemas na instalação da nuvem.
Instalei tudo do CD do Ubuntu Server 11.04, atualizei o sistema para a versão mais recente (apt-get update & apt-get dist-upgrade), instalei o NTP, configurei-o corretamente e inicializei tudo. A nuvem funciona ok por algum tempo, mas então o controlador de nuvem / controlador de cluster parará de falar com um dos controladores de nó!
Um dos sintomas é euca-describe-availability-zones verbose , de repente, começa a mostrar menos recursos do que os valores apropriados (e iniciais).
Se eu olhar em cc.log , será mostrado:
[Mon Sep 19 19:09:07 2011][002531][EUCADEBUG ] DEBUG: requested URI http://10.20.200.10:8775/axis2/services/EucalyptusNC
[Mon Sep 19 19:09:07 2011][002531][EUCADEBUG ] ncClientCall(ncDescribeResource): ppid=13403 client calling 'ncDescribeResource'
[Mon Sep 19 19:09:07 2011][002531][EUCAERROR ] ERROR: DescribeResource() could not be invoked (check NC host, port, and credentials)
[Mon Sep 19 19:09:07 2011][002531][EUCADEBUG ] ncClientCall(ncDescribeResource): ppid=13403 done calling 'ncDescribeResource' with exit code '1'
Em seguida, no controlador do nó correspondente, axis2c.log , vejo isto:
[Mon Sep 19 19:10:58 2011] [error] rampart_timestamp_token.c(179) [rampart]Timestamp not valid: Created time is not valid
[Mon Sep 19 19:10:58 2011] [error] rampart_sec_header_processor.c(612) [rampart]Timestamp is not valid
[Mon Sep 19 19:10:58 2011] [error] rampart_sec_header_processor.c(1911) [rampart]Timestamp processing failed
[Mon Sep 19 19:10:58 2011] [error] rampart_in_handler.c(143) [rampart][rampart_in_handler] Security Header processing failed.
[Mon Sep 19 19:10:58 2011] [error] phase.c(233) Handler RampartInHandler invoke failed within phase Security
[Mon Sep 19 19:10:58 2011] [error] engine.c(696) Invoking phase Security failed
[Mon Sep 19 19:10:58 2011] [error] engine.c(279) Invoking operation specific phases failed for operation ncDescribeResource
[Mon Sep 19 19:10:58 2011] [error] rampart_engine.c(159) [rampart][rampart_engine] Cannot get saved rampart_context
[Mon Sep 19 19:10:58 2011] [error] rampart_out_handler.c(136) [rampart][rampart_out_handler] ramaprt_context creation failed.
[Mon Sep 19 19:10:58 2011] [error] phase.c(233) Handler RampartOutHandler invoke failed within phase MessageOut
[Mon Sep 19 19:10:58 2011] [error] engine.c(696) Invoking phase MessageOut failed
Então: há um problema de sincronização de horário.
No entanto, o NTP está instalado e configurado corretamente.
Uma coisa que notei, ao emitir lotes de ntpq -np , é que o NC pára de funcionar quando o deslocamento de tempo é positivo . Se o offset ficar negativo, tudo funciona bem. As compensações são muito pequenas (em torno de 5ms, o máximo que pude ver é 10ms).
Pesquisando, encontrei este código de plataforma: link
/*Check whether created is less than current time or not*/
current_val = rampart_generate_time(env, 0);
validity = rampart_compare_date_time(env, current_val, created_val);
if (validity == AXIS2_SUCCESS)
{
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "[rampart][ts]Timestamp not valid: Created time is not valid");
AXIS2_FREE(env->allocator, current_val);
current_val = NULL;
return AXIS2_FAILURE;
}
Como podemos ver, aparentemente permite desvio no tempo em um sentido, mas não no outro.
Estou faltando alguma coisa? Eu sou o único que enfrenta esta questão? Não é estúpido verificar timestamps com precisão de milissegundos e permitir apenas desvios negativos?!
Como as pessoas lidam com esse problema? O que posso fazer para manter minha nuvem viva?
Pensei em algumas soluções:
ntp ou ntpdate ajustar o tempo para algum deslocamento específico por trás do tempo de referência do servidor O que você acha?
EDIT : parece que é possível desabilitar o Rampart na configuração do Axis2, mas não consigo descobrir como fazer isso!
EDIT 2 : A versão do Rampart disponível nos repositórios do Ubuntu é a 1.3.0, que é de 2007 ou 2008 ... a última versão lançada é algo como 1.6.0, a partir de junho de 2011. Aparentemente, esta última versão permite pacotes "do futuro". Eu realmente gostaria de encontrar esta última versão de um PPA!
EDIT 3 : Encontrei alguns parâmetros para alterar o comportamento do Rampart 1.3.0: TimeToLive, ClockSkewBuffer e PrecisionInMilliseconds. Eu os adicionei (360, 60 e false, respectivamente) ao EucalyptusNC.xml e EucalyptusCC.xml, e as coisas estão melhorando. Ocasionalmente eu ainda vejo as mensagens de erro de timestamp nos logs, mas elas são muito raras agora. Eu também desabilitei o NTP nos NCs e criei um script cron (que roda a cada hora) para sincronizar o tempo (ntpdate -b) com o CC.
EDIT 4 : Aparentemente este é um bug no pacote de Eucalyptus do Ubuntu. Eu registrei um bug no Launchpad, seguindo recomendações de pessoas no #eucalyptus no Freenode: link
Você encontrou um problema fundamental com a virtualização softare em geral e por extensão com virtualização baseada em nuvem, o relógio não está fundamentado em um relógio de hardware e flutuará em relação ao negócio geral do sistema operacional host subjacente. Ocasionalmente, o relógio físico e o relógio virtual serão sincronizados, causando um salto no relógio quando isso ocorrer. Existem muitos aplicativos em que esse salto de clock pode atrapalhar o desempenho do aplicativo. Onde você precisa de um relógio de alta precisão para fins de tempo ou auditoria, pode ser necessário migrar para hospedagem física em vez de hospedagem virtual na Internet.