Skocz do zawartości

elcct

WHT Pro
 Wyświetl profil  Zobacz jego aktywność

  • Zawartość

    1166

  • Rejestracja

  • Ostatnio

  • Wygrane dni

    19

Posty napisane przez elcct

  1. Napisano · Raportuj odpowiedź

    @Archi peceta zbytnio nie opłaca się co tydzień przewozić z Niemiec do Polski nie sądzisz? :)

     

    W cenie laptopa do gier, kupisz sobie dwie porządne stacjonarki i pewnie jeszcze na netbook-a na drogę starczy. Więc odpadnie Tobie problem transportu...

    Jak sobie kupisz dwie takie same, to wystarczy że w podróż zabierzesz sam dysk.

  4. Napisano · Raportuj odpowiedź

     

    Pisałem do nich o to tydzień temu, odpisali mi że jeśli serwery są w tym samym DC to nie potrzebna jest mi sieć prywatna ponieważ dane nie wychodzą z serwerowni więc zdaniem ovh działa to na zasadzie sieci prywatnej...

     

     

    Odpowiedź na poziomie OVH :) Tylko oni tną cały traffic (lokalny też) do tych teraz 250mbps. Więc trochę kiepsko np na jednym mieć bazę a na drugim serwis, przy dużym obciążeniu...

  6. Napisano · Raportuj odpowiedź

    Z pewnych wzgledow ja ze swojej strony polecam tylko plyty glowne firm Asus lub Gigabyte.

     

     

    Zawsze używałem płyt ASUS-a. Raz się skusiłem na płytę od Gigabyte i niestety po paru miesiącach były z nią problemy - częste restarty komputera, albo niebieski ekran. Zmieniłem potem płytę spowrotem na ASUS i problemy zniknęły. Ale to może miałem pecha po prostu :)

  7. Napisano · Raportuj odpowiedź

    Jest też problem, że niektórzy operatorzy ignorują TTL dla domeny, więc na pewno część użytkowników nie zobaczyłaby zmiany adresu IP przez wiele godzin. Ciężko jest jednak powiedzieć jaki to byłby procent użytkowników.

     

    Innym rozwiązaniem mogłoby być skorzystanie z firmy posiadającej kilka Datacenter w różnych lokalizacjach i oferującej IP Failover np. OVH. Jednak w porównaniu do VPS to by było znacznie droższe rozwiązanie - konieczność zakupu dwóch serwerów dedykowanych.

  8. Napisano · Raportuj odpowiedź

    Przenoszenie IP pomiędzy operatorami w razie awarii byłoby bardzo trudne.

     

    Myślę, że najłatwiejszym rozwiązaniem by było wykupienie usługi DNS u operatora który zapewnia redundancje swoich serwerów oraz niski TTL. Wtedy w przypadku awarii serwera VPS u jednego operatora, możnaby było zmienić IP podpięte do domeny do drugiego operatora. Z niskim TTL niedostępność strony by była na poziomie kilku minut.

  13. Napisano · Raportuj odpowiedź

    Tu nie tylko chodzi o testy, ale jak się ma zbudowany już jakiś klaster i przewiduje się wzrost użycia np. w związku z jakimś wydarzeniem albo kampanią reklamową, to dorzucenie paru "nodów" na ten czas i możliwość zapłaty tylko za tydzień to fajna sprawa.

     

    Jest to nawet ujęte jako jedno z zastosowań tej oferty "Uzupełnienie infrastruktury podczas zaplanowanego wzrostu obciążenia"


    Chyba OVH znów się przeliczyło ze sprzedażą serwerów. Maszyny stoją wolne więc ratują się czym mogą. Teraz serwery na tydzień daja ale nikt na forum nie wspomniał jaka cena a jest to 167,23 zł brutto więc w przeliczeniu miesięcznym ponad 600 zł.

    To samo daje Sprint tylko w cenie 30 zł netto.

     

    No ale w sprint możesz zamówić za te 30 zł netto kilka serwerów i potem np. za dwa tygodnie znowu kilka takich samych serwerów?

  14. Napisano · Raportuj odpowiedź

    Fajna sprawa i uważam, że to naturalna kolej rzeczy. Będzie to świetną konkurencją dla przereklamowanego "Cloud hostingu". Z czasem na pewno serwery dedykowane będzie można wynajmować na godziny.

     

    Jeśli jednak OVH nie będzie dotrzymywało szacowanych czasów otrzymania serwera, taka oferta nie będzie miała jednak większego sensu.

     

    Jeżeli ktoś liczy np. na kilkudniowy "peak" w związku z jakimś wydarzeniem, to jest szansa, że dostanie serwer za późno albo za wcześnie.

     

     

  15. Napisano · Raportuj odpowiedź

     

    Natomiast gdybym miał dzisiaj zmieniać architekturę - to bym nie wykorzystywał żadnej bazy - tylko napisał własną - idealnie dostosowaną do tego projektu - cholernie szybką i rozproszoną. Coś podobnego na kształt Terracota BigMemory - ale szybsze :)

     

     

    Są teraz ciekawe opcje do pisania baz pod konkretny projekt w Go przy użyciu np. Raft, LevelDB itd.

  16. Napisano · Raportuj odpowiedź

    Montowałem tylko 1 bazę ponad 1TB i uruchamialiśmy to na.... Mongo! Potem przejście na CouchDB ze względu na widzi mi się deweloperów tamtej aplikacji.

     

    Nie wyobrażam sobie skalowania do takich rozmiarów typowego SQLa, bo np. joiny i transakcje były by dość zaawansowanymi operacjami.

     

    Edit:

    MapReduce to potęga w takich przypadkach.

     

    Niestety ale SQL albo rozwiązania na Cassandrze lub Hadoop/Hive bardziej się nadają do większych baz. Ja sobie nie wyobrażam dużej bazy na Mongo, a w szczególności map reduce na niej, gdzie baza zwykle leży na czas zapytania.

    Czy możesz zaproponować jakieś rozwiązanie które pozwala PRZEŹROCZYŚCIE skalować postgresa na wiele maszyn ?

    (mam na myśli przeźroczyście dla aplikacji która korzysta z bazy)

     

    Niestety nie znam. Coś podobnego istnieje do bazy MySQL (vitess) ale jeszcze nie weszło w fazę produkcyjna. W każdym razie ciekawy projekt napisany w Go, polecam śledzić.

  17. Napisano · Raportuj odpowiedź

    To jakim cudem jest możliwość przeniesienia instancji bez downtime'u na inny node? Przecież takie operacje są wykonywane?

     

    Zawsze jest jakiś downtime, ale niektóre systemy ograniczają go do minimum, że jest niezauważalny.

     

    Jest taka możliwość, gdy wiele "matek" korzysta z tego samego storage. Wtedy aby przenieść VPS na inną matkę "przepinany" jest mount na inną matkę oraz przesyłany jest stan pamięci VPS (gdy VPS ma np. 1GB przy lokalnej sieci 10gbps to jest chwila) (tak mniej więcej działa vMotion)

  23. Napisano · Raportuj odpowiedź

    Poniekąd też tak myślałem, ale zastanawia mnie w takim razie jak działają chmury, np. Okravawe / e24cloud?

     

    Przypuśćmy, że mają nody po 32GB pamięci RAM (zapewne w rzeczywistości 128GB lub 256GB pamięci RAM, ale to mało istotne).

    Mają na takim jednym node dwóch klientów (chmury), każda po 14GB (w sumie daje to 28GB), jako że zasoby możemy sobie skalować przypuśćmy, że nagle jeden z klientów na tym node chce mieć 28GB pamięci RAM, w takim razie jego usługa chyba powinna automatycznie prze-migrować na drugi node, gdzie te 28GB jest faktycznie dostępne.

     

    Pewnie dzieje się tak, że jeżeli miejsce jest dostępne na node, to cloud pozostaje, jeżeli nie to migruje na wolny, czy tak w rzeczywistości to działa? Rozumiem, że w momencie migracji na inny node niezbędny będzie restart usługi i te kilka sekund przerwy są mimo wszystko nieuniknione, ponieważ i tak procesy clouda będą musiały zostać uruchomione na innej maszynie? Czy w taki sposób to działa?

     

    Tak, tak to działa. Jeżeli nie ma wolnego miejsca następuje migracja na serwer który takie miejsce posiada.

    W niektórych systemach migracja następuje wraz z adresami IP, na czas migracji VPS jest hibernowany i zwykle to niesie za sobą downtime. Niektóre chmury wymagają wyłączenia instancji przed zmianą parametrów. Zwykle bez restartu jedynie można zwiększyć ilość pamięci.

  24. Napisano · Raportuj odpowiedź

     

    Jeśli optymalizacja sprzętowa, wydajnościowa i kosztowa nie jest "sztuką", to co nią jest? Prosimy o choćby próbę otworzenia się na temat. Fotosik.pl oszczędza miesięcznie całkiem pokaźne sumy (i wiele innych firm również).

     

    Bardzo ładnie omijacie pytania :)

     

    Bardzo proszę - przykład: klient zakupił kilka serwerów dedykowanych na kilkuletnią umowę (wtedy wydawało się okazja), oczywiście musiał robić jakieś cuda typu mysql master-slave aby jakoś to działało. Obecnie za koszt wynajmu jednego takiego serwera, klient może wynająć jeden serwer, który z zapasem udźwignie cały serwis i przy okazji koszt spadnie kilkukrotnie. Z minimalnym wkładem - uproszczona architektura i spore oszczędności. Dlatego napisałem, że to nie sztuka.

×