Dobrze ze jest nagranie, można sobie to wszystko na spokojnie przerobić.
Świetna prezentacja - bardzo miło się słuchało, pozostaje teraz czekać na to samo o Azure.
AWS Dla Inżynierów Cisco - Ruszyła rejestracja na webinarium
-
minimalist300
- wannabe
- Posty: 346
- Rejestracja: 04 sie 2012, 22:52
- Lokalizacja: Cambridge/UK
Niestety nie moglem dolaczyc, wiec nadrabiam na Youtube:) Bardzo dobra sesja, dzieki Mirek.
Chcialbym dodac pare informacji waznych dla implementacji AWS:
1. Adresacja IP VPC - nie oszczedzajcie adresow IP przy poczatkowej adresacji VPC, gdyz po konfiguracji VPC nie mozna juz zmienic adresacji. Jedyny sposob to skasowanie calego VPC i stworzenie go od nowa.
2. "Router" pomiedzy subnetami w VPC - takie cos nie istnieje. Pakiety pomiedzy dwoma EC2 w dwoch roznych subnets sa dostarczane bezposrednio do instancji EC2. Ruch z jednej podsieci nie przechodzi przez jakikolwiek "wielki" router (na ktorym moze odbyc sie filtrowanie) aby trafic do innej. Jedyny sposob na wyfiltrowanie czegokolwiek, tak jak wspomnial Mikek to Network ACL (stateless) i Security groups (statefull).
3. Amazon uzywa mocno zmodyfikowanej wersji XEN jako hypervisorow.
4. AWS Direct Connect - w zaleznosci od implementacji AWS mozna stworzyc konto do ktorego przypisane jest Direct Connect i z ktorego wysylane sa pozniej "zaproszenia" do poszczegolnych VPC w roznych kontach. Z punktu widzenia polaczenia jest to zwykly .1q trunk od dostawcy (Partnera AWS) w ktorym poszczegone VLANy sa przypisywane do poszczegolnych kont.
Wielu providerow oferuje inne rozwiazania, takie jak np Verizon AWS SCI - roznica polega min na tym iz w przypadku SCI to provider konfiguruje sesje BGP i rozglasza prefixy z naszego VPC do naszej sieci enterprise/MPLS. W przypadku Direct Connect za BGP i rozglaszanie prefixow jestesmy odpowiedzialni my.
5 Niestery zadne L2 DCI nie dziala, AWS nie pozwoli nam sie wpiac w ich infrastrukture na poziomie L2, wiec OTV dzialac nie bedzie, a szkoda.
6. Jesli bedziecie kupowac rozwiazania sieciowe innych vendorow z AWS marketplace typu LoadBalancers, Firewalle czy nawet CSR1000V zwroccie duza uwage na przepustowosc oferowanych uzadzen. Dla przykladu CSR1000V = 2Gbps maxymalnej przepustowosci IPSEC przy c3.4xlarge EC2.
Dla kogos kto bedzie wdrazal AWS ponizszy link to podstawa aby zrozumiec ograniczenia architektury:
http://docs.aws.amazon.com/AmazonVPC/la ... imits.html
Wiele "limitow" jest elastycznych i AWS zmieni je na prosbe uzytkownika.
Dobrym zrodlem wiedzy sa prezentacje z AWS re:invent na Youtube.
Pozdrawiam,
Michal
Chcialbym dodac pare informacji waznych dla implementacji AWS:
1. Adresacja IP VPC - nie oszczedzajcie adresow IP przy poczatkowej adresacji VPC, gdyz po konfiguracji VPC nie mozna juz zmienic adresacji. Jedyny sposob to skasowanie calego VPC i stworzenie go od nowa.
2. "Router" pomiedzy subnetami w VPC - takie cos nie istnieje. Pakiety pomiedzy dwoma EC2 w dwoch roznych subnets sa dostarczane bezposrednio do instancji EC2. Ruch z jednej podsieci nie przechodzi przez jakikolwiek "wielki" router (na ktorym moze odbyc sie filtrowanie) aby trafic do innej. Jedyny sposob na wyfiltrowanie czegokolwiek, tak jak wspomnial Mikek to Network ACL (stateless) i Security groups (statefull).
3. Amazon uzywa mocno zmodyfikowanej wersji XEN jako hypervisorow.
4. AWS Direct Connect - w zaleznosci od implementacji AWS mozna stworzyc konto do ktorego przypisane jest Direct Connect i z ktorego wysylane sa pozniej "zaproszenia" do poszczegolnych VPC w roznych kontach. Z punktu widzenia polaczenia jest to zwykly .1q trunk od dostawcy (Partnera AWS) w ktorym poszczegone VLANy sa przypisywane do poszczegolnych kont.
Wielu providerow oferuje inne rozwiazania, takie jak np Verizon AWS SCI - roznica polega min na tym iz w przypadku SCI to provider konfiguruje sesje BGP i rozglasza prefixy z naszego VPC do naszej sieci enterprise/MPLS. W przypadku Direct Connect za BGP i rozglaszanie prefixow jestesmy odpowiedzialni my.
5 Niestery zadne L2 DCI nie dziala, AWS nie pozwoli nam sie wpiac w ich infrastrukture na poziomie L2, wiec OTV dzialac nie bedzie, a szkoda.
6. Jesli bedziecie kupowac rozwiazania sieciowe innych vendorow z AWS marketplace typu LoadBalancers, Firewalle czy nawet CSR1000V zwroccie duza uwage na przepustowosc oferowanych uzadzen. Dla przykladu CSR1000V = 2Gbps maxymalnej przepustowosci IPSEC przy c3.4xlarge EC2.
Dla kogos kto bedzie wdrazal AWS ponizszy link to podstawa aby zrozumiec ograniczenia architektury:
http://docs.aws.amazon.com/AmazonVPC/la ... imits.html
Wiele "limitow" jest elastycznych i AWS zmieni je na prosbe uzytkownika.
Dobrym zrodlem wiedzy sa prezentacje z AWS re:invent na Youtube.
Pozdrawiam,
Michal
Jeśli można to mam pytanko - czy jest tam nałożony jakiś limit na ruch dla poczty?
Mirek pokazal ze po wyłączeniu i włączeniu zmienia się adresacja serwera - czyli teoretycznie mogę wysłać kilkadziesiąt tysięcy wiadomości z jednego ip, wyłączyć i włączyć i dalej słać już z nowego IP? Wygląda mi to na raj dla spamerów
Adresacja ta z szkolenia jest czysta w najpopularniejszych listach:
http://mxtoolbox.com/SuperTool.aspx?act ... n=toolpage
Dodatkowo - ciekawi mnie jak mają rozwiązane logowanie takiej ilości danych, np takiej dynamiki zmiany ip.
Mirek pokazal ze po wyłączeniu i włączeniu zmienia się adresacja serwera - czyli teoretycznie mogę wysłać kilkadziesiąt tysięcy wiadomości z jednego ip, wyłączyć i włączyć i dalej słać już z nowego IP? Wygląda mi to na raj dla spamerów
Adresacja ta z szkolenia jest czysta w najpopularniejszych listach:
http://mxtoolbox.com/SuperTool.aspx?act ... n=toolpage
Dodatkowo - ciekawi mnie jak mają rozwiązane logowanie takiej ilości danych, np takiej dynamiki zmiany ip.
AWS nie pozwoli ci tak poprostu wyslac mass mailing zaraz po stworzeniu konta. Trzeba wyrobic sobie u nich dobra opinie - "nie spamera"Marek607 pisze:Jeśli można to mam pytanko - czy jest tam nałożony jakiś limit na ruch dla poczty?
Mirek pokazal ze po wyłączeniu i włączeniu zmienia się adresacja serwera - czyli teoretycznie mogę wysłać kilkadziesiąt tysięcy wiadomości z jednego ip, wyłączyć i włączyć i dalej słać już z nowego IP? Wygląda mi to na raj dla spamerów
Adresacja ta z szkolenia jest czysta w najpopularniejszych listach:
http://mxtoolbox.com/SuperTool.aspx?act ... n=toolpage
Dodatkowo - ciekawi mnie jak mają rozwiązane logowanie takiej ilości danych, np takiej dynamiki zmiany ip.
Tutaj jest wiecej informacji: https://aws.amazon.com/ses/
Jesli chodzi o logowanie, to niedawno zostala uruchomiona usluga ktora oferuje podstawowe logi sieciowe - VPC FLow Logs (z tego zo pamietam to nie jest dostepna we Frankfurcie)
Wlasnie - dodatkowe info to takie ze nie wszystkie uslugi sa uruchamiane we wszystkich regionach przez AWS. To co jest dostepne np w Irlandii moze nie byc dostepne we Frankfurcie. Zawsze to sprawdzcie, zanim wybierzecie region.
Dla tych co nie widzieli, to (prawie 2h)tu jest nagranie
@Kyniu - to ja dziękuję
@lbromirs - nie było od Ciebie pytań... ufff
@peper - ukłony
@Seba - podziel się wynikami - jestem ciekaw. Ja w tej chwili 100% pary w Azure, więc z chęcią poznam testy OTV w AWS, no i ofkoz business value idącą za nim. BTW: Coś mi jednak mówi, że OTV nie zadziała - https://clnv.s3.amazonaws.com/2015/usa/ ... C-2023.pdf
@minimalist300 i @Marek607 - Jak tylko się wgryzę w Azure, to zrobię. Mam jeszcze kilka niejasności.
@mikey81 - dobre komentarze. Temat sieci (aby go w pełni poznać) to 2-3 dni szkolenia (IMO) dla kogoś z CCNP, więc dobrze, że wrzucasz tu uwagi. Trochę uwag ode mnie:
1. Uwaga dotyczy początkowej adresacji w VPC - np. 10.10.0.0/16 - tego już nie można zmienić.
2. No nie dokońca. Zauważ, że zawsze masz GW i przez niego wychodzisz do innych sieci. W AWS jest to zawsze pierwszy adres z danej sieci. To jest wlaśnie ten "wielki"router, którego nie widać. Na tej też wartstwie zapinane są NACL.
5. Nie mówię nie, ale słyszałem gdzieś o terminuwaniu VPLSoverGRE pomiędzy VPC a DC. Nie znam use case, ale gdzię mi się to obiło. Czekamy na testy Seby
6. Słuszna uwaga.
Dzięki Michał i więcej komentarzy.
@Marek607 - w teorii tak, ale miej na uwadze, że AWS monitoruje a) to co się dzieje u nich b) to co krzyczą inni operatorzy pocztowi. Zakładając konto w AWS zgadzasz się na pewne zapisy umowy, które o spamowaniu mówią wyraźnie.
P.S. Jeszcze raz wielkie dzięki za tak liczne uczestnictwo i świetne pytanie. Bardzo mnie cieszy, że Wasza świadomość i doświadczenie awsowe części z Was jest wysokie. Dobrze to wróży dla przyszłych projektów, których pojawia się co raz więcej na polskim rynku.
@Kyniu - to ja dziękuję
@lbromirs - nie było od Ciebie pytań... ufff
@peper - ukłony
@Seba - podziel się wynikami - jestem ciekaw. Ja w tej chwili 100% pary w Azure, więc z chęcią poznam testy OTV w AWS, no i ofkoz business value idącą za nim. BTW: Coś mi jednak mówi, że OTV nie zadziała - https://clnv.s3.amazonaws.com/2015/usa/ ... C-2023.pdf
@minimalist300 i @Marek607 - Jak tylko się wgryzę w Azure, to zrobię. Mam jeszcze kilka niejasności.
@mikey81 - dobre komentarze. Temat sieci (aby go w pełni poznać) to 2-3 dni szkolenia (IMO) dla kogoś z CCNP, więc dobrze, że wrzucasz tu uwagi. Trochę uwag ode mnie:
1. Uwaga dotyczy początkowej adresacji w VPC - np. 10.10.0.0/16 - tego już nie można zmienić.
2. No nie dokońca. Zauważ, że zawsze masz GW i przez niego wychodzisz do innych sieci. W AWS jest to zawsze pierwszy adres z danej sieci. To jest wlaśnie ten "wielki"router, którego nie widać. Na tej też wartstwie zapinane są NACL.
5. Nie mówię nie, ale słyszałem gdzieś o terminuwaniu VPLSoverGRE pomiędzy VPC a DC. Nie znam use case, ale gdzię mi się to obiło. Czekamy na testy Seby
6. Słuszna uwaga.
Dzięki Michał i więcej komentarzy.
@Marek607 - w teorii tak, ale miej na uwadze, że AWS monitoruje a) to co się dzieje u nich b) to co krzyczą inni operatorzy pocztowi. Zakładając konto w AWS zgadzasz się na pewne zapisy umowy, które o spamowaniu mówią wyraźnie.
P.S. Jeszcze raz wielkie dzięki za tak liczne uczestnictwo i świetne pytanie. Bardzo mnie cieszy, że Wasza świadomość i doświadczenie awsowe części z Was jest wysokie. Dobrze to wróży dla przyszłych projektów, których pojawia się co raz więcej na polskim rynku.
GW do innych sieci? Z tego co kojarze to IGW i VGW beda mialy swoje IP addresy, kotre mozna skonfigurowac jako next hop.miboo pisze: 2. No nie dokońca. Zauważ, że zawsze masz GW i przez niego wychodzisz do innych sieci. W AWS jest to zawsze pierwszy adres z danej sieci. To jest wlaśnie ten "wielki"router, którego nie widać. Na tej też wartstwie zapinane są NACL.
Jednak jesli chodzi o ruch wewnatrz VPC pomiedzy subnetami to nie moge zadnego adresu IP znalec ktory sluzy jako default gateway dla poszczegolnej sieci.
Zastanawiam sie czy chodzi Ci o target dla 0.0.0.0/0 w route table, ktorego nazwa zaczyna sie od eni-... ??
mikey81 myślę, że to temat na inną dyskusję, aby nie zaśmiecać wątku. Dużo z tych rzeczy opisane jest tutaj.
P.S. Ta dyskusja pokazuje, że temat sieci jest dość duży i dlatego duże projekty chmurowe nie obędą się bez sieciowców.
Nie ma transferowania ruchu pomiedzy Subnet1 i Subnet2. Ruch przechodzi przez Router, który routuje go wewnątrz VPC pomiędzy sieciami. Gdy routing table wskazuje IGW, to Router przekazuje ruch do IGW (to samo z VGW).Your VPC has an implicit router.
P.S. Ta dyskusja pokazuje, że temat sieci jest dość duży i dlatego duże projekty chmurowe nie obędą się bez sieciowców.
Tutaj zdecydowanie sie z Toba zgodze - temat AWS i sieci jest bardzo rozlegly.miboo pisze:mikey81 myślę, że to temat na inną dyskusję, aby nie zaśmiecać wątku. Dużo z tych rzeczy opisane jest tutaj.
Nie ma transferowania ruchu pomiedzy Subnet1 i Subnet2. Ruch przechodzi przez Router, który routuje go wewnątrz VPC pomiędzy sieciami. Gdy routing table wskazuje IGW, to Router przekazuje ruch do IGW (to samo z VGW).Your VPC has an implicit router.
P.S. Ta dyskusja pokazuje, że temat sieci jest dość duży i dlatego duże projekty chmurowe nie obędą się bez sieciowców.
Jesli chodzi o router to mysle ze jest to kwestia interpretacji. Z punktu aplikacji network ACL to mysle ze jest to mozliwe, tak samo jak default gateway, chociaz z drugiej strony fakt ze nie ma jednego miejsca gdzie np. mozna monitorowac ruch pomiedzy subnets wewnatrz vpc, lub to ze ruch "wpadajacy" do sieci docelowej jest dostarczany bezposrednio do instancji EC2 moze obraz "routera" lekko zaburzac. Przynajmniej w mojej opinii.
AWS niestety nie pomaga nam w ujednoliceniu definicji gdyz jakiekolwiek techniczne szczegoly ich infrastruktury owiana sa tajemnica. Konsultanci AWS ktorzy z nami wspolpracuja od razu zmieniaja temat jak tylko o szczegoly zaczynamy ich pytac
Może wstydzą się przyznać co tam siedzimikey81 pisze:AWS niestety nie pomaga nam w ujednoliceniu definicji gdyz jakiekolwiek techniczne szczegoly ich infrastruktury owiana sa tajemnica.
Bo zazwyczaj jak jest się czym chwalić to marketing zaraz by wyciągnął to na sztandary jakie to mają super hiper rozwiązania.maly update w zwiazku z AWS:
-nowy region w Europie - Londyn - bedzie uruchomiony pod koniec 2016
-niedlugo dostepna bedzie usluga EFS - jest to NFS wedlug Amazon (powiekszy to oferte storage jaki bedzie mozna przypisac do EC2)
-obecnie w wersji preview (niedlugo zostanie wdrozone) - AWS Report - usluga ktora bedzie w stanie monitorowac srodowisko AWS pod wzgledem roznego rodzaju parametrow. Np mozliwe bedzie skanowanie wszystkich swoich instancji EC2 aby sprawdzic czy maja odpowiednio przypisane tagi.
-nowy region w Europie - Londyn - bedzie uruchomiony pod koniec 2016
-niedlugo dostepna bedzie usluga EFS - jest to NFS wedlug Amazon (powiekszy to oferte storage jaki bedzie mozna przypisac do EC2)
-obecnie w wersji preview (niedlugo zostanie wdrozone) - AWS Report - usluga ktora bedzie w stanie monitorowac srodowisko AWS pod wzgledem roznego rodzaju parametrow. Np mozliwe bedzie skanowanie wszystkich swoich instancji EC2 aby sprawdzic czy maja odpowiednio przypisane tagi.
