Bryan -
Aqui está o pequeno howto. Eu vou olhar para adicionar uma seção opcional para o Wiki que descreve isso.
# branch charms
bzr branch lp:charm/swift-proxy
bzr branch lp:charm/swift-storage
# create a config yaml file for the storage charm.
# the block-device setting needs to point to a block
# device that exists on *all* storage nodes, to be formated
# mounted and used as a backing store for objects
echo <<END >swift-storage.yaml
swift-storage:
block-device: xvda2
END
# deploy proxy
juju deploy --repository=$REPO local:swift-proxy
# deploy storage
juju deploy --config=swift-storage.yaml --repo=$REPO local:swift-storage
# add the relation
juju add-relation swift-proxy:swift-proxy swift-storage:swift-proxy
# add 2 more units to give us the minimum 3 required nodes
juju add-unit swift-storage
juju add-unit swift-storage
Isso deve fornecer um cluster funcional que mantém 3 réplicas de cada objeto. Ele pode ser usado como seu próprio cluster separado ou você pode vinculá-lo ao restante de sua nuvem Openstack para ser usado como armazenamento de back-end para suas imagens de VM:
juju add-relation glance:object-store swift-proxy:object-store
Você pode testar isso usando o provedor EC2 se não tiver 4 servidores extras por aí.
Algumas notas:
- Os atuais swift charms eram mais uma prova de conceito e não são projetados para permitir que os nós de armazenamento aumentem e diminuam muito bem.
- Você precisará de 4 nós no total para implantar isso (1 proxy, 3 armazenamento)
- Os charms atuais usam um sistema de autenticação falso e obsoleto chamado tempauth. Com o Keystone adicionado como um componente principal do Openstack, o swift deve estar usando isso para autenticação / autorização (charme de Keystone em breve)
- Existem alguns itens de trabalho neste ciclo para expandir / reescrever os swift charms para permitir dimensionamento, autenticação contra keystone e aproveitamento dos recursos de Juju que ainda permitem a seleção inteligente de máquinas e posicionamento de encantos.