kafi

Kwestia co kto lubi Ale ogólnie to Nokia raczej wycofuje się z tego systemu, więc na siłę nie ma się IMO do niego co pchać...

Jeszcze bardziej chore jest liczenie w matlabie działania 2+2, gdzie spokojnie średnio rozwinięty szympans policzy to w pamięci

NC - może warto pomyśleć nad udostępnieniem strony statusowej NOC poza własną siecią szkieletową, to by frustrację takich niedzielnych klientów lekko ostudziło

Nie tylko tobie nie działa. Śledzenie trasy do ncgroup.pl [194.24.175.245] z maksymalną liczbą 30 przeskoków: 1 * * * Upłynął limit czasu żądania. 2 44 ms 46 ms 44 ms lodz-ru2.neo.tpnet.pl [213.25.2.133] 3 lodz-r2.tpnet.pl [213.25.5.81] raporty: Sieć docelowa jest nieosiągalna. Śledzenie zakończone.

Jak to nie ma, jak jest? Na wszystkim działającym na ProFTPd userek sobie sam może kontrolować poszczególne operacje na swoich zasobach. Jak mi się będzie nudzić, to zrobię krótkie howto, jak nie zepsuć sobie przy okazji zabaw dostępu z konta macierzystego.

Dokładnie o to mi chodziło. Jeśli ktoś rozprasza usługi to ok. Ale jeśli ktoś i tak kisi to na jednym marnym vpsie, to wtedy nie dość, że taka zabawa mu nic pożytecznego w sumie nie da, to jeszcze zamiast podawać po prostu dwa hosty NS przy rejestracji domeny, to będzie musiał ją dodawać gdzieś indziej, tam konfigurować i na to coś delegować.

Czyli chmura to opisywany przeze mnie w jednym z poprzednich postów VPS używający ? Eee... zdziwił byś się, ile owych "potocznych ofert" jeździ właśnie na VMware albo XenServer z dopiętą macierzą NAS. Takie PS: ja wcale nie neguję usługi zwanej "chmurą". Ale głównie staram się podkreślić to, że w poważniejszych zastosowaniach korporacyjnych mechanizmy te wykorzystywane już są od dawna i o wielkich "nowościach" nie ma co tak naprawdę mówić. Bo owa "chmura" dla mnie to tylko marketingowe sprzedanie tych mechanizmów szczęśliwemu klientowi dzięki czemu owy ogrom mechanizmów można streścić do jednego słowa-klucza.

Sponsi - jeśli utnie ci router (grupę routerów) który wg tablicy routingu sąsiadów powinien być tym last-hopem, to nie ma siły - do czasu aktualizacji tych tablic routingu przez jakiś działający w tle protokół routingu to raczej troszkę czasu minie i troszkę strat się pojawi. Z resztą - w większości przypadków nawet awaria peera BGP to jakieś minuty częściowej niedostępności z niektórych systemów autonomicznych... To jest bardzo dobre pytanie W sam raz na nową dyskusję ;]

Będziesz charytatywnie poświęcał swój czas, żeby mości klientom poprawiać różnego rodzaju wadliwe aplikacje? Przecież to jak sam napisałeś nie jest takie trudne... Przeciętny user właśnie tylko będzie obwiniać usługodawcę, że coś DZIAŁAŁO a NIE DZIAŁA i to jego wina. Klasyczny taki dialog podałem w poprzednim swoim poście. Ano to, że niektórzy programiści owe "bugi" w swoich aplikacjach wykorzystywali jako "ficzery". Część także może nie dosłownie - ale kod pomimo programistycznego błędu (jeszcze) działał, a po poprawkach interpretera przestał.

Może inaczej. Jakaż to strategiczna usługa? Nie działanie serwera VPS i tak spowoduje, że odwzorowanie do niego będzie w 99% bezużyteczne. Podasz jakiś argument, dla którego bardziej zadowalająca będzie dla ciebie odpowiedz do nieosiągalnego adresu IP, niż odpowiedź SERVFAIL? Co innego, jeśli ktoś stawia rozwiązania niezawodnościowe. Ale wtedy to raczej posiada kilka różnych "maszyn" (czy to fizycznych, czy to wirtualnych), z których w razie awarii może serwować usługi WWW (chociażby komunikat "zaraz wracamy"), odbierać backupowo pocztę itp.

Rufik, nie zrozum mnie źle, ale ja pytam, jak bezprzerwowo ruch przepiąć do zapasowego centrum w razie KrytycznejAwarii głównego, a ty proponujesz mi redundancję rurki. Taki sobie prosty scenariusz (w Polsce w teorii nierealny, ale znając kaprysy Matki Natury to kto go tam wie...) niespodziewanego trzęsienia ziemi, gdzie optolinki się pourywają, prąd zniknie, a użycia agregatu zabronią służby ratunkowe. Zanim to rozgłosisz w BDC, to troszkę jednak czasu minie. Więc IMO zawsze będzie jakiś czas niedostępności usług, choć nie wiem jakich zabezpieczeń byś nie stosował. Kwestia tylko, co by był on jak najmniejszy. Ale do tego nie potrzeba "chmury"

Wytłumacz mi jak krowie na rowie, w jaki sposób bezprzerwowo (skoro dostępność ma być 100%) przepniesz to IP na inne routery brzegowe, jeśli owemu obiektowi, w którym są balancery dalej je rozgłaszające coś urżnie wyjście na świat / jakaś siła go uszkodzi? PS: Uptime to czas życia maszyny, a nie procenty... procenty to DOSTĘPNOŚĆ... ile można to wałkować...

A jak rozwiązać problem #29 - nagłej fizycznej niedostępności całego obiektu?

Skoro to jest VPS, który strony www i pocztę trzyma pod jednym adresem IP, to cóż da mu klaster serwerów secondary, które wskazywać będą na nie działający serwis? Druga sprawa - uważasz, że VPS z podpiętymi do siebie dwoma adresami IP i do nich dopiętymi ns1/ns2 będzie bardziej PRO?

No tak, dla ciebie może nie są trudne. Ale w momencie apdejtu zacznie się klasyczny zapętlony dialog admina i programisty Co niektórzy pamiętają boje np. z wyłączeniem register globals, magic quotes, ewentualnie problemy z MySQL.5 i nie chcą powtarzać awantur związanych z takimi grubymi rewolucjami

Hipotetycznie - to może i tak. Ale popatrzmy realnie - niech przyjedzie sobie Przyjaciółeczka-Kopareczka i niechcący urwie aorty płynące do DC. Wytłumacz mi waść, jakimi mechanizmami zrealizujesz bezprzerwowe przejęcie ruchu? Rozgłosisz w innym końcu świata adresację IP? To zanim się to rozpropaguje po całej sieci - zanim inne inody zobaczą awarię, poza tym - zanim sam protokół BGP rozgłosi to do każdej zabitej dechami wiochy, to i tak będzie jakiś downtime. Podmienisz wpisy DNS? To zawsze znajdzie się jakiś keszogenny resolver, który nie zauważy owej zmiany i klient też ma downtime. Nie mówiąc o tym, że do dwóch ww. rozwiązań nie potrzeba wcale chumury - bo firma z sensownym NOCem jest w stanie zrobić to obecnymi środkami. Więc w sumie także nihil novi, może jedynie tyle, że dostępne pudełkowo.

Piszecie, że zwiększanie zasobów on-demand to taka wielka nowość. Przecież przy stosowaniu OpenVZ to kwestia wydania poleceń vzctl set 1010 --vmguarpages 256M --save vzctl set 1010 --oomguarpages 256M --save vzctl set 1010 --privvmpages 256M:512M --save Więc nihil novi. Replikacja istniejącego to skopiowanie na żywca drzewa katalogów i podpięcie pod to nowego configa. Także nihil novi. Szczególnie, jeśli korzystamy z jakiegoś w miarę inteligentnego SANa z obsługą deduplikacji. Kwestia dostępności... jeśli uwali się chmurowy supervisor, to ciężko będzie wywróżyć, co jest gdzie, i to rozproszenie i tak się na nic nie zda. Kwestia bezpieczeństwa danych - jw. - jeśli wyparuje centralny supervisor, to danych możemy sobie szukać po poszczególnych nodach i je sobie sklejać - powodzenia Tak podsumowując - owa chmura, to marketingowe nazwanie technologii, które są same w sobie stare jak świat, no ale w lepszym "sreberku" można je sprzedać po prostu droożej

Spróbuj ProxyPassReverse /app http://twojadomenaaplikacji.pl/serwis

Zadam nieco durne pytanie z innej beczki - jakie łącze posiadasz na tym wynalazku? Może po prostu przy większej ilości ssanych zasobów je sobie wysycasz, i dlatego coś ci "muli"? Bo jeśli dobrze zrozumiałem zasadę działania - to przez curl coś pobierasz (sporej dawki transfer przychodzący + conieco wychodzącego na kontrolę przepływu) no i to dalej wysyłasz (tutaj znowu sporo uploadu i tyci downloadu).

Dziwią mnie takie debilizmy. To co, stawiam sobie anonimowo serwer w OVH, nałożę tam shaperda 128kbit/s i będę się z moim ISP procesował, że nie mam prędkości 20Mbit i to niezgodne z prawem itp itd? A jeśli chodzi o usługi przepływu danych - to tam zazwyczaj jeśli ktoś chce, to dowolnie ukształtuje sobie CIR i EIR. Oczywiście odpowiednio za to płacąc

Cóż, nie wiedziałem, że MZone ma na imię Kacper, ale to w sumie logiczne odwracać kota ogonem swojego pracownika i robić z niego biedną ofiarę niedobrego pana Kafiego, który się na pewno uwziął Jeśli będą lądować ot tak sobie w koszu, to tak. Ale jeśli będzie w nich adnotacja: usunięto przez XYZ z powodu złamania reg. par. 1.8 to raczej problemu być nie powinno. Dane firmy będą zajmować jakieś trzy linijki posta. A pozwolą w prosty sposób pokazać, kto tak naprawdę za tym stoi. A jeśli rozwiązywać to przez konto firmowe, to cóż, można i w ten sposób. Ale najpierw to trzeba by precyzyjnie zdefiniować, co to jest FIRMA. Czy np. (tu już wybitnie personalnie) Sys-Com, czy też może wszystkie podmarki tworzone przez Sys-Com (CastPol.pl, Pro-Serwer.com i inne) to FIRMY osobne. Na koniec drogi Miłoszu - na stronie reklamowanej przez Kolopika pełnych danych firmy nie ma.

Przeczytaj post #5. W skrócie - twój serwer hostingowy twierdzi, że ta domena jest lokalna i nie widzi potrzeby analizy rekordów MX.

1) Jak się pracuje, to się wyniki swojej pracy archiwizuje 2) Jak się sępi sponsoring, bo na serwer nie stać, to miłym gestem jest informować sponsora o tym, że na jego darmowych usługach się chce tyci zarobić, no i czy nie ma on nic przeciwko. Nie odwrotnie. Bo wyraźnie z twojego postu wynika, że użytkownicy płacili smsem za dostęp do serwera i dlatego są nieco źli, że nie działa... 3) To nauczka, także dla hdmagc - szczególnie takie rzeczy, jak sponsorowanie, powinny być zwieńczone pisemną umową obu stron. Bo inaczej to właśnie takie kwiatki powstają, że sponsor jest zajefajny, ale jak nie da oprócz palca całej ręki, to odbywa się zbędny lament i śmiecenie.

Z poziomu jakiego użytkownika wywołujesz skrypt startowy fcgi?

Podanie czterech różnych NSów, z których każdy zwraca coś innego, to dosyć błędne koło, które poprawnie zadziałać to nie ma prawa. Sytuacja pierwsza - to w recordsecie zwracanym od root-serverów domeny PL nie ma priorytetów, więc rekursor wylosuje sobie jeden z czterech i go zapyta o adres. Istnieje więc spore prawdopodobieństwo, że delikwent trafi do serwera backupowego pomimo poprawności działania serwera primary. Sytuacja druga - to jeśli sobie jakiś resolwer zapisze do cache wartość odwzorowania domeny na adres IP, to nawet w razie padu, to nie zaktualizuje tego, tylko zwracać będzie staroć, który kierować będzie do nikąd. To samo w przypadku, gdy klient już będzie znać odwzorowanie do backupowego, to będzie je jakiś czas pamiętał i w razie przywrócenia działania podstawowego serwera i tak nie będzie szybko do niego przełączony. Takie rozwiązania to robi się zazwyczaj przy pomocy klastra serwerów z loadbalancerem na zewnątrz; ostatnio nawet czasami modnie zwanego "chmurą".