_MK_

Zapraszamy. Lokalizacja: ATMAN (Warszawa) Wirtualizacja: pełna, VMware vSphere Brak limitu ilości przesłanych danych - limitujemy pasmo dostępne dla danego środowiska wirtualnego. Możliwość uruchomienia filtrowania pakietów dla środowiska - bez dodatkowych opłat. Zapewniony backup środowiska wirtualnego. Adres testowy: 91.239.61.30 Przykładowa oferta: RAM: 1GB CPU: 1GHz Sieć: 10 Mbit/s, symetrycznie HDD: 10GB OS: FreeBSD 9.1 (amd64/i386) Cena: 99 zł netto/miesiąc Minimalny czas świadczenia usługi: 3 miesiące NIe wymienił Pan dokładnej specyfikacji jaka Pan interesuje, zapraszamy do kontaktu, możemy dopasować ofertę i ponegocjować biuro(at)waw.net.pl -------------------------------------------------- Waw.Net.Pl ul. Dębicka 29/29, 01-461 Warszawa NIP: PL 522-254-25-37, REGON: 142981947 http://www.waw.net.pl

Rzecz w tym, że przestrzeń IPv4 w RIPE dla podmiotów nie mających statusu LIR już się skończyła. Alokacje z ostatniej /8 są jedynie dla LIR (co prawda nie więcej niż /22) - zatem posiadanie tego statusu w obecnej sytuacji daje pewne korzyści, przynajmniej w kontekście IPv4.

Myślę, że nikt tu nie podważa jakości usług Waszego dostawcy jakim jest ATM. Proponuję żebyście usunęli ze schematu bezpośredni styk z Telia i wszystko będzie ok . Wynik z LG Telia pokazuje rzeczywistość (IPv4) - czyli ruch z Telia via ATM (Global.Transit,as24724). 195.177.216.0/23 *[bGP/170] 2d 11:20:29, localpref 200, from 213.248.64.245 AS path: 24724 57239 I to 80.91.253.187 via ae3.0 to 80.91.253.170 via ae6.0 to 213.155.134.42 via ae4.0 to 80.91.246.98 via ae5.0 to 80.91.246.100 via ae9.0 > to 213.155.134.44 via ae7.0 to 213.155.132.158 via ae11.0 to 213.155.132.160 via ae12.0 [bGP/170] 2d 11:20:29, localpref 200, from 213.248.64.246 AS path: 24724 57239 I to 80.91.253.187 via ae3.0 to 80.91.253.170 via ae6.0 to 213.155.134.42 via ae4.0 to 80.91.246.98 via ae5.0 to 80.91.246.100 via ae9.0 > to 213.155.134.44 via ae7.0 to 213.155.132.158 via ae11.0 to 213.155.132.160 via ae12.0

Dojście światłowodem/światłodowami do DC też zwykle zakończy się portem/portami na switch`u/switach`ach. Mozna powiedzieć, że mają "ostatnią milę" łatwo skalowalną z 1G do 10G, której nie zagrozi żadna koparka .

Z FreeBSD nie będzie problemu, zapraszamy do kontaktu z biuro(at)waw.net.pl

Dodam jeszcze, że podpisanie odpowiedniej umowy z firmą zza oceanu a następnie jej ewentualne egzekwowanie na drodze sądowej może być trudne. Wiadomo, że bez podpisania umowy trudno mówić o jakichkolwiek gwarancjach. Z polską firmą będzie zdecydowanie łatwiej.

To prawda cena nie będzie niska, ale jeśli najważniejsza jest jakość a cena ma drugorzędne znaczenie wtedy warto to rozważyć. Z wypowiedzi autora wątku wnioskuję, że chodzi przede wszystkim o jakość w postaci natychmiastowej reakcji w razie problemów co zagwarantuje właściwa umowa z firmą o odpowiednim potencjale. Jakość MUSI kosztować.

Myślę, że tu bardziej wskazana jest nie "firma z kimś", ale firma utrzymująca dyżurujący zespół NOC 24/7. Jeśli operator dyżurny nie jest w stanie poradzić sobie z problemem wtedy obudzi "kolejną linię wsparcia". Może warto skorzystać z obsługi jakiegoś polskiego centrum danych posiadającego w swojej ofercie usługi typu cloud + zarządzanie z gwarancją czasu reakcji? Zdaje się, że ATM SI ma usługi zarządzania dołączone do swojej oferty "cloud services": http://www.atm-si.com.pl/uslugi/cloud_computing_services ATM ma w swoim portfolio dość wymagających klientów, może i w tym przypadku dadzą radę?

Rozwiązanie z SFTP które opisałeś ma jedną dość istotną wadę - port na którym słucha openssh musisz wystawić dla świata. Rozumiem, że przez "to samo SSH" dostajesz się na swoje konto z którego potem administrujesz maszyną? Wszystko zależy od przyjętego modelu bezpieczeństwa, ale jeśli już mówimy o poprawianiu "security" to dobrą praktyką jest otworzyć dostęp do SSH jedynie dla tych którzy muszą go naprawdę mieć - samych administratorów. Można zdefiniować ograniczoną pulę "zaufanych" adresów IP mających dostęp do portu na którym słucha SSH lub stosować np. port knocking (http://doorman.sourceforge.net/ ). Stosując openssh jako system do bezpiecznej transmisji plików pokusiłbym się o stworzenie separowanego środowiska (np. oddzielny jail/chroot) dla którego zakładane byłyby konta z powłoką jedynie dla SCP lub jeśli nie byłoby to możliwe dla kont z powłoką inną niż SCP stosowałbym autentykację jedynie po certyfikatach. Ps.: Poza wspomnianym rssh spotkałem się jeszcze z powłoką "scponly" (http://sourceforge.net/projects/scponly/), sprawowało się nie najgorzej.

Ponadto ceny w LIM-PLIX nie należą do najniższych co przekłada się na rentowność wielu przedsięwzięć. Poza tym przełączniki PLIX`a są fizycznie rozlokowane również w Telehouse.Poland, czyli w ATM. Czyli używając wspomnianej przez Ciebie nomenklatury będąc w ATM-Telehouse również jesteś "w sercu ..." (cokolwiek by to miało znaczyć )

Moze FreeDOS Ci wystarczy? Na WWW masz gotowe ISO. http://www.freedos.org/freedos/files/

Pinging pw.edu.pl [194.29.151.5] with 32 bytes of data: Reply from 194.29.151.5: bytes=32 time=2ms TTL=52 Reply from 194.29.151.5: bytes=32 time=7ms TTL=52 Reply from 194.29.151.5: bytes=32 time=2ms TTL=52 Reply from 194.29.151.5: bytes=32 time=3ms TTL=52 Ping statistics for 194.29.151.5: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 2ms, Maximum = 7ms, Average = 3ms Pinging 62.67.42.208 with 32 bytes of data: Reply from 62.67.42.208: bytes=32 time=18ms TTL=51 Reply from 62.67.42.208: bytes=32 time=18ms TTL=51 Reply from 62.67.42.208: bytes=32 time=18ms TTL=51 Reply from 62.67.42.208: bytes=32 time=18ms TTL=51 Ping statistics for 62.67.42.208: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 18ms, Maximum = 18ms, Average = 18ms Zapraszam do zapoznania się z ofertą Waw.Net.Pl, wirtualizacja Vmware vSphere: http://www.waw.net.pl

Jak najbardziej. FreeBSD jest wspierane m.in. przez vSphere. Zapraszam do zapoznania się z ofertą Waw.Net.Pl: http://www.waw.net.pl

Zapraszam do zapoznania się z ofertą Waw.Net.Pl - gwarantujemy indywidualne podejście i wysoką dostępność infrastruktury. http://www.waw.net.pl

Można tu przytoczyć dość sporo rozwiązań - diabeł tkwi w szczegółach . Serwer główny będzie miał połączenie z zapasowym po LAN? Z kontekstu można wywnioskować, że chcesz mieć tu jednak środowisko rozproszone geograficznie - w takiej sytuacji DNS przyjdzie z pomocą. Pytanie jaką zawartość serwujesz via WWW i FTP - jeśli jest dynamiczna to musisz zadbać również o jakąś synchronizację (rsync, synchronizacja baz danych - bez odpowiedniego podejścia można popaść w niezłe kłopoty). Co do maila w sensie SMTP to secondary MX powinien wystarczyć - co do POP3 i IMAP to również powstaje problem synchronizacji. Jeśli rozwiązanie ma być proste, gotowe i zapewniające przy tym szybki failover WWW to może rzuć okiem np. na: http://www.zoneedit.com/failover.html Zasadniczo sprawy zapewnienia redundancji potrafią być naprawdę skomplikowane - używając komercyjnych rozwiązań również dość kosztowne.