Parece que você está no caminho certo para o que precisa. As tecnologias por aí (GlusterFS, GPFS) têm os recursos que você está procurando, mas não a localização de dados. Dependendo do que você está fazendo com os dados, isso pode ser incorporado ao seu despachante de trabalhos.
Para mim, parece que você precisa compilar em um estágio de indexação para o pipeline de processamento que determina a localidade de dados. Isso pode ser paralelizado e depois serializado novamente em um banco de dados, embora essa etapa provavelmente seja um código personalizado (você conhece seus dados melhor do que eu). Depois que você tiver a localidade de dados, as unidades de trabalho de processamento de pacotes para nós do trabalhador devem ser relativamente simples; construir unidades de trabalho para dados locais de nós primeiro e depois adjacentes a nós (se esse conceito se aplicar ao seu caso) e finalmente um contexto global usado quando a maioria do processamento é feito, mas algumas unidades de trabalho parecem estar tomando uma idade e seu processador local de nó está ocupado mastigando-os.
Essa é uma visão de alto nível. Focando mais perto dos parafusos do problema. A julgar pelo que você disse até agora, parece que você está trabalhando em grandes blocos de dados e deseja que o processamento seja feito no armazenamento local por motivos de largura de banda. Vejo algumas opções:
Primeira ideia, quando os dados são ingeridos a partir da sua fonte, são copiados para o Gluster / GPFS / qualquer sistema de arquivos distribuído. Em seguida, execute o processo de indexação que descrevi acima. Em seguida, à medida que os trabalhadores processam dados, os conjuntos de dados processados são reportados de volta a outro grupo de servidores cuja função é fornecer dados processados por HTTP. O método report-back pode até ser feito via HTTP PUTs, que depois coloca os dados em outro sistema de arquivos replicado. A desvantagem desse método é que ele armazena seus dados duas vezes (original e modificado), mas não sei se é algo que você já está fazendo. Isso permite que você amplie sua infra-estrutura de processamento até certo ponto, ao mesmo tempo em que mantém a infra-estrutura de serviço do cliente muito pequena.
Segunda ideia, como acima, mas quando os trabalhadores terminam de processar uma unidade de trabalho, os dados salvos são armazenados no sistema de arquivos Gluster / GPFS / whatever. Em seguida, os servidores HTTP veiculam dados diretamente desses repositórios, mas eles não estão tão preocupados com o nó-local quanto os nós de processamento. Para isso, é provavelmente uma boa ideia ter redes separadas de serviço e processamento de clientes para limitar o problema de trânsito duplo com esses grandes conjuntos de dados.
Terceira ideia, se descobrir a localidade de dados do GPFS / Gluster não for realmente factível (não os usei, por isso não tenho a certeza) poderá querer criar o seu próprio tipo de armazenamento. É muito trabalho, se você realmente precisa de localidade, pode valer a pena para você. À medida que você ingerir dados, cada conjunto de dados é indexado em um banco de dados e HTTP PUTed para vários nós, conforme necessário. Quando o processamento acontece, as tarefas são criadas para nós individuais para dados que são locais do nó para si mesmos primeiro. Quando um trabalhador recebe um trabalho, ele HTTP obtém os dados do nó especificado pelo banco de dados (que deve ser em si, mas não precisa ser). Quando o trabalho é concluído, ele notifica o banco de dados e recebe instruções sobre onde COLOCAR os resultados.
Para veicular conjuntos de dados processados para clientes, você provavelmente terá que introduzir algum código de aplicativo para converter arquivos para buscar HTTP GETs com proxy de seus nós.
Isso introduz uma parte de alta largura de banda do processo na forma desse banco de dados. Ele pode ter vários servidores da Web com balanceamento de carga na frente para processamento de lógica, mas o próprio banco de dados acaba sendo um ponto único de falha (embora as pessoas mais experientes nas formas de bancos de dados possam saber formas de contornar isso) . O banco de dados está basicamente atuando como a tabela de alocação de arquivos para um grande sistema de arquivos baseado em HTTP. Já que seu processamento parece precisar de semântica de sistema de arquivos muito simples (buscar / colocar, possivelmente bloquear / desbloquear para um nó que está processando um conjunto de dados) que pode ser mediado por tal banco de dados. Obviamente, esse banco de dados será muito grande, portanto, algumas das tecnologias NoSQL podem ser mais adequadas por motivos de desempenho.
Eu sei que esta não é a tecnologia específica que você está procurando, é mais sobre técnicas para lidar com deficiências no mercado. A localidade dos dados e a replicação é algo como um caso extremo, parece. Acontece que fazemos algo semelhante a você apenas com conjuntos de dados menores, por isso é um assunto que está na minha mente também.