W

edług “Wprowadzenia do systemów rozproszonych” charakterystyczne opóźnienie pomiędzy węzłami ( serwerami / agentami / procesami / aktorami ) wynika z: operacji wewnątrz samych węzłów, które są “szybkie“; operacji pomiędzy węzłami, które są “wolne” – co jest szybkie, a co wolne zależne jest od tego, co wykonuje sam system. Za przykład posłuży nam klaster, który komplet danych utrzymuje po części na każdym węźle wchodzącym w jego skład. Czyli klient odpytując klaster o część interesujących go danych może odpytać o nie dowolny węzeł, ale musi poczekać aż jego odpowiedź zostanie złożona z danych zwróconych przez każdego uczestnika w klastrze. Tak na przykład działa shardowanie danych w Elasticsearch.

Do dyspozycji aplikacji są dwa klastry umieszczone w dwóch różnych centrach danych. Pierwszy posiada słabsze czasy odpowiedzi mimo wydajniejszej konfiguracji sprzętowej (Cluster #1), drugi natomiast szybsze czasy odpowiedzi i słabszą od pierwszego konfigurację sprzętową (Cluster #2). Jedyną różnicą w ich konfiguracji jest rozłożenie fizyczne serwerów w ramach centrum danych. Pierwszy z nich posiada węzły, które są dalej od siebie (inne szafy rack, kioski lub moduły); drugi natomiast oprócz kilku serwerów jest zamknięty w ramach jednego przełącznika sieciowego (ang. switch). Zgodnie z powyższą zasadą mówiącą o szybkości operacji pomiędzy węzłami – to migracja komponentów pierwszego klastra do możliwie najbliższych ścieżek sieciowych, a najlepiej jednego wspólnego modułu powinna wyrównać, a nawet polepszyć jego czasy odpowiedzi. Co, jeśli spojrzymy na wykres czasów odpowiedzi po takiej migracji – stało się prawdą.