Tiktalik.com

Alwaro, tak jak wspominalem. Przeslij mi na priv badz na daniel.esposito@tiktalik.com oferte. Chetnie przekaze ja w dobre rece. Pozdrawiam, Daniel

Witaj, zobacz cennik VPS'ow na http://tiktalik.com/pricing - IP mozemy dorzucic po 4PLN netto/mc sztuka. pozdrawiam, Daniel

Poslij do nas informacje na priv, byc moze bylibysmy zainteresowani. Liczba klientow, marka, miesieczne przychody, miesieczne koszty. pokazemy komu trzeba, Daniel

Witam, prosze spojrzec na http://tiktalik.com/ Dla tego typu uzycia, przy laczu 20Mbps mozemy zaproponowac obnizke na instancje 4U do 100PLN netto, badz obnizke 30% na jakakolwiek instancje. Wszystkie instancje dzialaja na dyskach SSD co pomoze przy predkosci kompilacji prosze napisac na kontakt@tiktalik.com proszac o znizke po wybraniu odpowiedniej instancji, powolujac sie na nasza korespondencje. pozdrawiam, Daniel

spoko

@ksk: moglbys tez potestowac takie rozwiazanie u nas, zaraz po swietach bedziemy dodawac usluge loadbalancera HTTP, dzieki ktoremu bedzie mozna uzyskac HA/loadbalancing. Takie rozwiazanie vs odpalanie kolejnej wirtualki na loadbalancer ma takie plusy, ze loadbalancer jest wysokodostepny i loadbalancowany sam w sobie. Przez co nie trzeba odpalac na niego samemu 2 wirtualek i kombinowac z keepalived itd. Bedziemy to uruchamiac kolo 9 maja

'stand on the shoulder of giants' Tyle, ze dodawanie kolejnych watpliwych warstw nie nada temu rozwiazaniu predkosci. Najbardziej ciekaw jestem ile trzeba tego backendu doladowac, zeby zaczelo byc 'szybko' przy duzej liczbie zapytan/rownoczesnych polaczen.

@KRIS ciekawi mnie, dzialasz juz produkcyjnie? Ile masz zapytan na sekunde? Jaki transfer, jak Ci to wszystko chodzi?

Ja bym strzelal tak: - twoj VPS wspoldzieli zasoby z innymi - ktos regularnie na matce odpala jakas prace, ktora zajmuje zasoby IO - dysk staje sie masakrycznie wolny, apache przechodza w stan D (DISK a nie DEAD), czekania na IO, na dysk czekania, kazdy taki czekajacy dodaje 1 do loadu. Zmienianie na workery, srery nie ma sensu. Serwery event driven nie moga miec loadu > 1 bo tylko jeden proces moze czekac na IO, niestety specjalnie im to w przypadku wolnego IO nie pomaga, bo i tak jest wolno. Wyraznie widac, ze staje ci IO.

@Pajter: chetnie pogadamy na tematy architektoniczne, ew zaproponujemy architekture / hosting, administracje.

Ewidentnie jezdzisz po dysku, kazdy proces oczekujacy na IO dodaje 1 do loadu. Jak masz kurczace sie zasoby to odpalanie kolejnych procesow apache'a nie ma sensu, lepiej ustawic ich mniej, wtedy przynajmniej nie bedziesz wchodzil w overload i wywalenie systemu. Mozna postawic z przodu proxy, ktore troche skolejkuje ruch wchodzacy a na apache'u mniej procesow. Mozesz tez pomyslec o szybszym IO.. pozdrawiam

Jakie potrzeby, wielkosc bazy, ruchu itd? Trudno oferowac cos konkretnego oprocz zachecenia do odwiedzenia strony, jesli nie podajesz zadnych szczegolow. pozdrawiam, Daniel z Tiktalik.com

@yogi: Moze rozdziel dane statyczne (sterowniki) od samej strony. Skrobnij do nas, zaproponujemy serwer na WWW / baze oraz oferte na skladowanie i serwowanie statycznych rzeczy z naszego systemu.

My nie wspoldzielimy zasobow dyskowych pomiedzy serwerami, jesli wezmiesz instancje zajmujaca caly serwer fizyczny, jestes sam i masz dla siebie 70 000 IOPS. Rozumiem wiec, ze jako klient, nie wspominajac o cenie: a) zauwazasz problem z serwerami o duzej ilosci ram w chmurze - trudno dostepne oferty b) wybierasz dla swoich biznesow dedyki o 'sredniej' cenie, bo nie wierzysz, ze 'tanio' mozna zrobic cos dobrze Dzieki, notujemy punkt widzenia. My mamy zamiar wkrotce odpalic serie 'Eco' w naszym IaaS, czyli serie tanich serwerow i3/i5 8/16/32GB RAM w formie zwirtualizowanej, bez dzielenia zasobow dyskowych (kupujacy instancje o rozmiarach calego serwera ma go dla siebie). Moim zdaniem to bedzie polaczenie dobrej ceny dedyka + latwosc obslugi i elastycznosc. Oczywiscie pozostana kwestie 'zaufania', ktore poruszales. dzieki za wymiane zdan, Daniel

Proponuje zaczac uzywac okreslenia IaaS, poniewaz 'chmura' jest pojeciem rozmytym, niektorzy moga udowadniac, ze serwery dedykowane to tez chmura, nie chce tutaj wchodzic w jakies flame wars, uzywajmy wiec dalej okreslenia IaaS. @TheOne, przyjmujesz w swoim wywodzie dotyczacym chmury dwa zalozenia, ktore moim zdaniem nie zawsze sa prawdziwe. Mianowicie: - zalozenie 2-3 krotnie wyzszej ceny serwera w rozwiazaniu IaaS z zarzadzana wirtualizacja vs serwer dedykowany, mysle, ze obecnie jesli spojrzy sie na polskie oferty serwerow dedykowanych mozemy mowic o roznicy dwukrotnie mniejszej 1.5 - 1.8 razy - zalozenie wspolnego storage dla klientow rozwiazania IaaS, nie wszyscy dostarczyciele infrastruktury podchodza do tematu w ten sposob, my dla przykladu uwazamy, ze istotniejsze jest zmniejszenie ryzyka zwiazanego z padem macierzy niz agregowanie zasobow dyskowych, dlatego do naszych serwerow dajemy direct attached storage Jesli chodzi o potrzebne zaufanie to: - odnosnie udostepnionych zasobow, tak, potrzeba zaufania, natomiast w rozwiazaniach IaaS, ktore bardziej eksponuja sprzet i daja direct attached storage, tego zaufania potrzeba 'mniej' - owszem, zaufac nalezy, ze zabezpieczenia dostarczyciela uslugi nie pozwola atakujacemu dostac sie na serwery fizyczne - odpieranie atakow - to jak rozumiem ten sam argument co punkt wyzej? Jesli zalozymy, ze dostawca IaaS nie prowadzi polityki wspoldzielenia storage oraz klient ma wykupiona instancje wypelniajaca maszyne fizyczna, 'awaria chmury' musi nastapic gdzies w warstwie sieciowej, co implikuje podobny wplyw na usluge serwerow dedykowanych oraz usluge IaaS z instancjami zwirtualizowanymi. Odnosnie stageowania/testowania - oczywiscie, testuje sie w odrebnym srodowisku, w ogromnych instalacjach mamy jednak czesto do czynienia ze stageowaniem, czyli powolnym rolloutem nowych wersji przetestowanego oprogramowania na poszczegolne czesci systemu, co zmniejsza ryzyko wystapienia niewykrytego bledu. Tak czy inaczej tutaj obaj zgadzamy sie, ze IaaS jest lepszy niz dedyki, bo bardziej elastyczny. Owszem, dzielenie serwisu na front i back ma rowniez swoj bardzo istotny aspekt bezpieczenstwa, zgadzam sie. Wydajnosc jest rowniez wieksza, gdyz baza danych lepiej sobie moze radzic z cachowaniem danych, gdy nie musi walczyc o pamiec z pozostalymi serwisami. Kwestie dwoch DC pozostawiam na inne rozwazania, to samo mozna robic w IaaS na dedykach itd, zawsze wiele DC jest rozwiazaniem lepszym niz jedno (chyba, ze ktos nie ma zamiaru duplikowac kosztow serwerow, swoja droga w IaaS, taki backup mozna odpalic on-demand ). Nie dyskutujmy tutaj o tym, to zbyt szeroki temat. Argument odnoszacy sie do zaniku zasilania podpiera sie blednym zalozeniem , ze wszystkie 'chmury' wspoldziela storage. Przy takim zalozeniu, oczywiscie mozesz miec racje i mielismy juz takie przypadki. Bardzo dziekuje za Twoj punkt widzenia, pozwoli nam lepiej zrozumiec sposob myslenia niektorych klientow. Moze bedziemy mogli dodac do naszej oferty rowniez rozwiazania dla nich/dla Ciebie. Stad ponizsze pytania: - czy twoim zdaniem oferta serwerow dedykowanych z cenami podobnymi do OVH/Hetzner ale zlokalizowana w Polsce spotkala by sie z Twoim i innych zainteresowaniem? - byc moze rozwiazanie hybrydowe, gdzie klienci mieliby dostep zarowno do dedykow oraz opcji IaaS na maszynach zwirtualizowanych, jest tym, co pozwoliloby klientom wykorzystac zalety obu rozwiazan u jednego dostawcy? dzieki jeszcze raz za zabranie glosu i prosze o opinie, pozdrawiam, Daniel z Tiktalik Team

Panowie, dostawca IaaS daje wam w zasadzie to samo, co dedyki + latwosc wlaczania/wylaczania, robienia backupow, przywracania starych obrazow, klonowania systemow itd. Odnosnie 'wrzucmy wszystko na jeden serwer': @elcct: Przyzwyczajeni jestesmy do wiekszych serwisow niz 100mln PV/mc, ale dobrze, policzmy troche: Niech to bedzie serwis, ktory ma 90 000 000 odslon miesiecznie. 3 000 000 odslon dziennie, zalozmy, ze cos sie tam dzieje w ciagu 16 godzin na dobe, czyli mamy 52 zapytania na sekunde. Jesli aplikacja jest dobrze napisana, nie ma dlugich zapytan, moze ja udzwignac e3, z wieksza iloscia ramu i szybkim dyskiem SSD. Mamy jednak w takim modelu nastepujace problemy: - awaria serwera wylacza nam serwis - nie mamy latwej drogi do zwiekszenia wydajnosci serwisu, powiedzmy 4 krotnie. - nie ma metody na latwe 'stageowanie' zmian i testowanie nowych wersji serwisu bez destabilizacji calosci Mozna wiec podejs do tematu w nastepujacy sposob, typowa tiered architecture: - dzielimy serwis na front endy (serwery WWW, gdzie chodzi aplikacja + cache) - serwery bazy danych Zamiast jednego serwera dedykowanego, mozemy wlaczyc np 3-4 male serwery WWW (tak by awaria ktoregos z nich nie powodowala problemow serwisu), oraz 1 badz 2 serwery bazy danych (jesli chcemy wieksza dostepnosc, master-slave). mamy dzieki temu: - wysoka dostepnosc serwisu (awaria ktorejkolwiek z maszyn wirtualnych nie prowadzi do przestojow w dzialaniu serwisu) - latwosc skalowania - dodajac kolejne maszyny frontendowe badz slave'y bazy danych skalujemy sie horyzontalnie, powiekszajac instancje kazdej z nich wertykalnie - latwosc stageowania/testowania zmian - nowy kod mozna deployowac na jednej z maszyn WWW nie wplywajac na dzialanie pozostalych - sypiamy spokojniej, bo przy awarii nie trzeba biegac jak oszalaly czekajac az support cos tam podniesie, zwiekszenie ruchu obslugujemy dodajac klony maszyn frontendowych Koszt w przyblizeniu wychodzi nam podobny jak w rozwiazaniu dedykowanym. Np 5 x 100 ~ 500 PLN

Np od nas

Nie rozumiem, twierdzisz, ze prawidlowo wykonana strona zawsze bedzie w stanie udzwignac load na pojedynczym serwerze i ze uzycie load balancera to cos zlego? Skad takie zalozenia? Moim zdaniem podzielenie serwisy nawet intencjonalnie na kilka mniejszych instancji, to dobra praktyka. To ciekawa dyskusja architektoniczna.

Moim zdaniem chmura dzialajaca w modelu IaaS, czyli dostarczyciel infrastruktury, daje klientowi elastycznosc, latwosc zarzadzania. Ci, ktorzy nie mieli do czynienia z wiekszymi systemami czesto nie zdaja sobie sprawy z tego jak sprawy sie komplikuja, jesli serwerow jest wiecej. Jesli chodzi o bezpieczenstwo, to jest ono takie, jak zarzadzi nim klient. @beliq: co dokladnie Ci sie nie podoba, zalezy nam na feedbacku od potencjalnych klientow. Jesli nie chcesz nas linczowac publicznie, moze byc na priva. Daniel

No to moze bardziej konkretnie: a) serwery dedykowane / wlasne oprogramowanie. Nalezy napisac oprogramowanie, ktore: - instalowalo bedzie potrzebne programy na serwerach dedykowanych - przetrzymywalo 'lokalizacje' klienta (ktory klient na jakim serwerze) - loadbalancowalo ruchem przychodzacym, by klient trafial na swoj serwer Zarzadzanie sprzetem: Nalezy zadbac o rozsadne dokupowanie serwerow, wymiane czesci w serwerach i zadbac o przywracanie danych, backupy itd. Nie kupowac za duzo serwerow, jednak jak rosnie ruch moc szybko dokupic serwerwy dedykowane by sprostac zapotrzebowaniu b) chmura / wlasne oprogramowanie loadbalansujace Nalezy napisac oprogramowanie, ktore: - uruchomi kolejny serwer za pomoca API dostawcy chmury - utrzymywac informacje ktory klient na jakim serwerze - loadbalansowac klientow pomiedzy serwerami Mozna miec obraz z zainstalowanym calym oprogramowaniem per serwer i odpalac kolejne ich instancje wykorzystujac API - prosta sprawa Zarzadzanie Sprzetem: Nie trzeba angazowac kapitalu w serwery dedykowane na dluzszy okres, mozna elastycznie wlaczac/wylaczac serwery oszczedzajac czas i gotowke. Podsumowanie: w obu rozwiazaniach nalezy zajac sie wlasnorecznie loadabalancerem, zarzadzanie oprogramowaniem i maszynami w chmurze jest 10 x latwiejsze, czas reakcji na obciazenie / popyt w chmurze krotszy Jesli chcialbys pomocy przy takim projekcie jestesmy w stanie nawet stworzyc oprogramowanie do zarzadzania takim oprogramowaniem na naszej infrastrukturze, odezwij sie na kontakt@tiktalik.com pozdrawiam, Daniel

Panowie/Panie, kolejny raz widac jak bardzo historyczne przyzwyczajenie polskich klientow do 'shared storage' wplywa na mylne zalozenia klientow dotyczacych uslugi i nie wykonuja backupu we wlasnym zakresie. Co wiecej raid czy 'near realtime backup', ktory znamy z ofert niektorych firm, trudno uznawac za backup przeciwdzialajacy ludzkiemu bledowi czy wlamaniu - skasowanie waznych danych jest wtedy kopiowane na 'near realtime backup' czy drugi dysk w RAID. Generalizujac, klienci nie robia backupow, mentalnie zakladaja, ze tymi sprawami zajmuje sie dostawca IaaS, tak jak to bylo w shared storage a jednoczesnie wybieraja uslugodawcow kierujac sie glownie cena. Oczywistym jest, ze przy takich parametrach rynku/mentalnosci zdarzac sie beda sytuacje jak wyzej. Pamietajmy o backupie !! pozdrawiam

@patrys: wyslane

Ostatnio przycieli chyba do 200Mbps per serwer dla klientow, ktorzy naduzywali. Juz nie jest tak kolorowo.

Do uslugi mozna podejsc dwojako. Badz udostepniajac 'hardware' taki i taki, badz stwierdzajac, ze klient dostanie tyle a tyle IOPS czy tyle a tyle GB przestrzeni. W tym drugim podejsciu, wlasciciel chmury, moze optymalizowac infrastrukture ponizej i im lepiej to zrobi, wiecej zarobi. Im wyzszy poziom uslugi w stacku, tym bardziej ta regula jest prawdziwa. Tak czy inaczej informacja 'do XXX IOPS' nie sugeruje gwarancji. Bardzo ciekawym jest natomiast porownanie kosztow Tiered storage do uslugi, gdzie mamy direct attached storage udostepniony uzytkownikami pod maszyna wirtualna. Powiedzmy aplikacja generujaca 20 000 IOPS w szczycie, 10 000 IOPS w nocy. Srednio dajmy jej 15 000 IOPS. W ciagu miesiaca bedziemy mieli 720h * 3600s * 15 000 IOPS = 38880 milionow IOPS W cenniku Oktawave utrzymanie takiej aplikacji na powiedzmy 50GB danych bedzie kosztowalo: 38880 milionow IOPS * 0.04 = 1555.2 PLN 50 GB * 720h * 0.003 PLN (Tier-2 - jesli 'do 20k IOPS uciagnie nam w szczycie 20k IOPS) = 108 lub 144 dla tier-3 czyli za SAM storage zaplacimy okolo 1700 PLN, do tego jakies CPU/Pamiec, powiedzmy 15GB ramu no i cos co odpowiada e3-12XX, licze za to okolo 500pln w przyblizeniu. Razem mamy 2200 Klient Placi w tym modelu 2200 PLN/mc Jesli natomiast klient wybierze usluge chmury, gdzie 'hardware' jest bardziej wyeksponowany i wykupowac moze instancje dzialajace jako jedyne na konkretnych serwerach, moze uruchomic swoja instancje jak nastepuje: - 150 GB SSD, co mu daje powiedzmy srednio 50 000 IOPS non stop, bo nie dzieli z nikim zasobow - xeon e3-12XX - 15 GB ramu zaplaci 550 PLN.. Jesli klient bedzie chcial dodatkowo miec niezawodna aplikacje i nie wystarczy mu przywracanie bazy z automatycznego backupu i postawi sobie slave'a do bazy, zaplaci 1100 PLN, bedzie przy okazji mial dla aplikacji znacznie wieksza wydajnosc. Uslugi w chmurze opakowywac mozna roznie, liczac na zaspokojenie roznych klientow i ich potrzeb. pozdrawiam,

Stream3: Ponownie zachecam do kontaktu, jestesmy w stanie przedstawic unikalna w sensie technicznym i cenowym oferte w zakresie 1-100Gbps pozdrawiam, mamy zaawansowany rozproszony system dedykowany do podawania duzej ilosci danych kontakt@tiktalik.com pozdrawiam, Daniel Esposito Tiktalik Team