Po pierwsze, wyjaśnię ci moją sytuację. Prowadzę dość popularną stronę internetową jako projekt poboczny, więc nie mogę naprawdę zainwestować w to mnóstwo pieniędzy. Obecnie mam tylko jeden serwer z HAProxy z przodu wysyłającym normalne żądania do Apache i wszystkie żądania plików statycznych do Lighttpd. Działa to naprawdę dobrze, ponieważ wszystkie żądania php i post są obsługiwane przez Apache, podczas gdy wszystkie obrazy są wysyłane do szybszego Lighttpd (strona to głównie obrazy, więc jest to naprawdę ważne). Byłoby miło nie musieć konfigurować subdomeny do obsługi obrazów, ponieważ krótkie adresy URL są również bardzo ważne, dlatego mój powód do korzystania z HAProxy.
Znalazłem dostawcę hostingu, który oferuje dość tanią, niepomierną przepustowość, z której korzystałem, problem pojawia się, gdy zaczynam wypychać tyle przepustowości, ile karta sieciowa 100 Mb / s może obsłużyć, a zatem potrzebuje drugiego serwera.
Zastanawiałem się nad moimi opcjami, więc wyjaśnię wam każdą z nich. Mam nadzieję, że możesz podać wgląd w to, która z nich jest dla mnie najlepsza, a może jest jeszcze jedna opcja, o której jeszcze nie myślałem.
Wymagania:
Nawet dystrybucja przepustowości jest koniecznością. Mam dość wydajny serwer, więc skalowanie w górę nie wchodzi w grę. Muszę zwiększyć skalę, aby uzyskać większą przepustowość.
Krótkie adresy URL. Naprawdę nie zamierzam konfigurować poddomeny, takiej jak img.example.com, aby wyświetlać moje obrazy. przyklad.com/image.jpg jest taki, jaki jest teraz i jak bardzo chciałbym, aby został. Ale jeśli nie ma innego wyjścia, rozumiem.
Serwer Clostest obsługujący żądanie byłby naprawdę fajny, ale nie był koniecznością. O czym należy pamiętać.
HAProxy do loadbalance:
- Byłoby to naprawdę łatwe, ponieważ i tak już używam HAProxy. Myślę jednak, że problem pojawia się przy rozdzielaniu przepustowości. Mogę się mylić, ale czy HAProxy nie wysyła żądania do serwera, na którym serwer je przetwarza, a następnie odsyła za pośrednictwem HAProxy do klienta? W ten sposób cały ruch jest wycofywany przez moduł równoważenia obciążenia, co powoduje, że zużywa tyle pasma, co wszystkie serwery łącznie.
DNS Round Robin:
- To może być moja najlepsza opcja. Po prostu powiel stronę internetową na wielu serwerach i rób to, co teraz robię. Minusem jest to, że jeśli jeden serwer ulegnie awarii, klienci nadal będą do niego wysyłani. Musiałbym również replikować witrynę na wielu serwerach. Miałem nadzieję, że mogę mieć jeden główny serwer, który obsługuje wszystko oprócz plików statycznych, a następnie mieć kilka statycznych serwerów plików. Przeczytałem również, że było to coś w rodzaju „równoważenia obciążenia biednego człowieka” i byłoby miło mieć coś bardziej wyrafinowanego.
Bezpośredni zwrot z serwera:
- Wydaje się to bardzo skomplikowane, ale może być dobrą opcją. Czy nadal będę mógł wysyłać określone adresy URL do niektórych serwerów? Podobnie jak w przypadku HAProxy, każdy adres URL, który kończy się odpowiednim rozszerzeniem pliku, jest wysyłany do Lighttpd, podczas gdy inne rozszerzenia są wysyłane do Apache. Potrzebowałbym więc czegoś podobnego. Podobnie, wszystkie żądania php są obsługiwane przez ten sam serwer, na którym działa oprogramowanie równoważące, podczas gdy wszystkie żądania jpg są wysyłane do wielu serwerów.
Idealnie, gdyby HAProxy obsługiwał Direct Server Return, wtedy mój problem zostałby rozwiązany. Nie chcę też korzystać z CDN, ponieważ są naprawdę drogie, a przecież to tylko poboczny projekt.
Czy rozumiesz mój problem? Daj mi znać, jeśli nie wyjaśniłem czegoś poprawnie lub potrzebujesz więcej informacji.
Odpowiedzi:
Narysuj obraz cyklu zapytania / odpowiedzi dla aplikacji i izoluj wąskie gardło. Masz rację, że jeden serwer proxy dystrybuujący obciążenie na wiele serwerów aplikacji będzie wymagał łącznej przepustowości wszystkich serwerów aplikacji. Klasycznym rozwiązaniem jest RR DNS. Google, Yahoo i Amazon używają tej techniki w krótkim TTL. Jakiś czas temu przeprowadziłem dochodzenie i udokumentowałem swoje ustalenia .
Innym rozwiązaniem jest zastosowanie fantazyjnego rozwiązania do równoważenia obciążenia w przedsiębiorstwie, wykorzystującego wirtualne adresowanie IP do równoważenia żądań między wieloma serwerami aplikacji z prawdziwymi adresami IP. Pracowałem z produktami Netscaler i Stonesoft. Oba działają dobrze, ale mają okropne osobliwości i są dość złożone.
źródło
Niektóre odpowiedzi:
Czy potrzebujesz uwierzytelnienia na żądanie obrazu? Jeśli nie, to co powiesz na użycie czegoś takiego jak Amazon S3? Jest masowo skalowalny, a koszt przesyłania danych jest dość tani. W takim przypadku użyłbym czegoś takiego jak i.sitename.com jako DNS CNAME dla nazwy hosta segmentu Amazon S3, zobacz dokumentację Amazons . AFAIK: nie możesz mieć nazwy domeny głównej (sitename.com) jako CNAME, więc musisz do tego użyć subdomeny takiej jak i.sitename.com.
Możesz również mieszać swoje obrazy na wielu serwerach. Tzn. Tworzysz strukturę DNS, taką jak login.sitename.com i a.sitename.com; b.sitename.com; c.sitename.com i tak dalej. „A.” oraz b." itp. serwery zawierają po prostu system plików z obrazami i lekki serwer HTTP (już używasz Lighttpd, więc kontynuuj korzystanie z niego. W przyszłym projekcie proponuję przyjrzeć się nginx jako lepszemu zamiennikowi.) Gdy użytkownik przesyła obraz, tworzysz skrót unikalnego identyfikatora, być może jego nazwy użytkownika, być może nazwy pliku lub kombinacji wielu identyfikatorów . Na podstawie tego skrótu określasz, na którym serwerze przechowywać obraz.
Edytuj Powinienem był zobaczyć, że hashowanie zostało już omówione. Zasadniczo to, co proponuję tutaj, to po prostu użycie haszowania na nazwie hosta, aby równomiernie rozłożyć ruch sieciowy na wielu hostach.
Nie wiem, jak tanio to musi być - ale kiedy przesuwasz 100 MBit ruchu sieciowego, wtedy „tani i dobry” szybko okazuje się iluzją. Może powinieneś najpierw rozważyć uzyskanie dobrego modelu biznesowego, który zapewnia powtarzalne dochody, a następnie wdrożyć odpowiednią technologię?
źródło
Zakładam, że HAProxy jest na tym samym serwerze, co inne aplikacje? Możesz podzielić HAProxy na inny system, aby uruchomić żądania i pozwolić mu wysyłać normalne żądania do jednego serwera, a żądania obrazów do innego serwera. Problem polega na tym, że wszystkie żądania wciąż trafiają do jednego urządzenia, a jeśli nasycasz przepustowość, to może ci nie pomóc.
Mówisz, że krótkie adresy URL są ważne. Dlaczego? Czy to naprawdę wielka sprawa, aby zmienić obrazy z „example.com” na „i.example.com”? Możesz ustawić „i” na własny adres IP na własnym serwerze za pomocą Lighttpd i całkowicie ominąć HAProxy, rozwiązując problem z przepustowością. Przydałaby się również przeglądarka internetowa, umożliwiająca jednoczesne otwieranie większej liczby żądań, ponieważ uznałaby je za różne nazwy domen i mogłaby otwierać więcej jednoczesnych połączeń. Jeśli pojedynczy serwer „i” zostanie nasycony, możesz użyć okrągłego robina DNS, aby dodać kolejny. Mam nadzieję, że do tego czasu generujesz wystarczające przychody, aby wdrożyć lepsze rozwiązanie.
źródło
Czy Twój dostawca hostingu oferuje usługi równoważenia obciążenia? Myślę, że to najlepsze rozwiązanie.
Innym sposobem, aby to zrobić, ale należy to przetestować, jest przepisanie (w lighty lub apache) żądań. Na przykład: example.com/plik.html pozostaje w Apache, a example.com/image.jpg przekierowuje do i.example.com/image.jpg. Wszystkie żądania będą zarządzane przez apache, ale odpowiedzi (przepustowość w górę) trafiają do serwera lighttpd. Domena jest przezroczysta dla użytkownika. Nadal musisz sprawdzić, czy apache może obsłużyć wszystkie żądania, czy może lighttpd może wykonać tę pracę.
Masz rację, wszystkie dane przechodzą przez HAProxy, więc nie możesz (o ile wiem) wykonać bezpośredniego zwrotu serwera.
AKTUALIZACJA
Patrząc w dokumentacji HAProxy znalazłem parametr „redir”. Nie wiem, czy to działa jak przepisanie apache, ale może być przydatne. Dokumentacja mówi:
Może to działa w twoim przypadku.
źródło
Zakładam, że przy każdym dużym zestawie obrazów nie przechowujesz obrazów na podstawie ich oryginalnej nazwy pliku, ponieważ dość szybko natrafisz na konflikty nazw.
Wiele aplikacji zajmujących się tego typu problemami używa skrótu pliku i struktury katalogów opartej na tym skrócie. Struktura katalogów wygląda następująco: ścieżka katalogu to pierwsze dwa znaki skrótu, a katalog drugiego poziomu to kolejne dwa znaki skrótu.
Zaletą jest to, że skróty utrzymują równomierną dystrybucję plików i zapewniają przestrzeń nazw, którą można łatwo podzielić na wiele serwerów. Zasadniczo podajesz części przestrzeni mieszającej z różnych serwerów, a podczas skalowania możesz ją dalej dzielić w razie potrzeby.
Minusem jest to, że skróty nie są idealne i mogą wystąpić kolizje. Nie jestem pewien, jak sobie z tym poradzić. Może to zająć trochę badań z twojej strony. Wyobrażam sobie, że reguła przepisywania w proxy powinna być w stanie pobrać skrót, powiedz A3A8BBC83261.jpg i przepisać go na http://img3.domain.com/A3/A8/BBC83261.jpg . Nie możesz jednak uznać tego za krótki adres URL.
źródło
W swoim poście wspomniałeś, że uważasz, że okrągły DNS może być najlepszą opcją, ale martwiłeś się o awarię jednego serwera ...
W takim przypadku spójrz na Simple Failover z JH Software. Używałem go w przeszłości i działa bardzo dobrze.
http://www.simplefailover.com
Zasadniczo monitoruje twoje serwery, a kiedy zobaczy, że jeden z nich zejdzie, szybko przepisuje DNS, aby wyciągnąć martwy serwer z rotacji.
Oto fragment z ich strony internetowej:
Jak wspomniano wcześniej, używałem go w przeszłości zarówno na stronach internetowych, jak i serwerach pocztowych. Działał dość dobrze. Przełączanie awaryjne było w większości przypadków dość szybkie (zgadywanie 2–5 minut) i powiedziałbym, że prawie wszyscy ponieśli porażkę w czasie krótszym niż 15 minut.
Niekoniecznie IDEALNY ... ale zdecydowanie szybki i łatwy.
UWAGA: To jest produkt Windows. Nie jestem pewien, czy mają wersję linux, czy nie, ale możesz przełączyć się na dowolny serwer, który ci się podoba, ponieważ oparty jest na DNS.
W naszym przypadku po prostu wrzuciliśmy go na maszynę XP, powiedzieliśmy maszynie, aby uruchamiała się raz na noc i działała dobrze przez lata.
źródło