A következő címkéjű bejegyzések mutatása: Amazon EC2. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: Amazon EC2. Összes bejegyzés megjelenítése

2014. június 4., szerda

Windows Server 2012 R2 végre...

Tudom, hogy a szerkezet nem új. Csak az én környezetemben. Eddig tartott a remek Amazon AWS-nek, hogy végre publikáljon Windows Server 2012 R2 alapú image-eket. Alig nyolc hónap. Ennyi idő alatt már majdnem egy gyereket is ki lehet hordani.

2013. október 1., kedd

Fejezetek az Amazonos hétköznapokból 1.

Valami bénázásom folytán a két DC-nk pingeni tudja egymást, de a B zónában lévő DC-ről nem tudok szolgáltatásokat elérni az A zónában lévő DC-n.
Próbálkoztam mindennel. Nem jött össze.
Itt jött amikor az ember nem figyel és mellényúl. Kinyírtam a gép default gateway-ét.  Minden kapcsolat elszállt, RDP kimúlt.
Ugyebár az Amazonban nincs konzol, tehát onnan nem tudom javítani. Az adott subneten nincs másik gépem.
Tehát gyártunk egy új instance-t oda (kb. 20 perc), belépünk, onnan RDP, gateway beállít, új instance nyakonvág, örül.

Másfél hete küzdök azzal, hogy összerakjam a Microsoft Dynamics CRM 2011-et és az AD FS 2.1-et. Tegnap végre sikerült. Ma megpróbáltam az éles adatbázis másolatát átvinni a teszt CRM-re. SMB másolás két gép között ugyanazon a subneten, egyszerűen nem működik.
Próbáltam a 15GB-os fájlt átmásolni nem ment.
Próbáltam 100 megás tömörített szeletekben, az sem ment.
Maradt az, hogy plusz kötet felcsatol, oda a DB backup kirak, kötet lecsatol, teszt gépen felcsatol, restore, örül.

Egyszerű az élet az Amazonban.

2013. szeptember 17., kedd

Gratulálunk Amazon!


No Comment...

P.S.:
Ha valaki nincs otthon Amazonban.
m1.large - $180/hó
m2.xlarge - $375/hó

2013. szeptember 14., szombat

Amazon EC2 - Windows PPTP

Első nap (este):
Jelentkezett a főnököm, hogy mi a helyzet a Windows Server 2012-es átállásunkal. Én balga elkezdtem vele beszélgetni. Mondtam, hogy a két DC kész van, a FSMO role-okat átbillentettem. Mondta, hogy látni szeretné. Kiderült, hogy az OpenVPN-je nem működik. Miután ezt a kollégám csinálta és még nem tudok eleget róla nem akartam hibakeresni este 7 felé. Mondtam neki, hogy ott a PPTP ami még félkész (DirectAccess-t kell összeraknom, de ha már az ott lesz akkor miért ne menjen rajta más VPN kapcsolat is). Mondtam 2 perc, összerakom. A 2 percből 3 óra kínszenvedés lett.
Az Amazon security policyban ügyesen a 1723-as UDP portot állítottam be a TCP helyett. Amikor erre rájöttem még mindíg problémás volt a kapcsolódás.
Gondolkoz gondolkoz.
A hálózat amiről beszélek a VPC (Virtual Private Cloud) LAN-ja (egy internettől elzárt 10-es IP tartomány)
Az Amazon egy fura szerkezet. Láthatóan minden interface routolt. A DHCP a sajátjuk, ha egy interface-hez nem állítok be egy címet a webes felületen akkor, ha fejem tetejére állok sem fog azon kommunikálni a gépem. Elkezdtem csalni. A VPN szerver hálózati interface-ére felvettem annyi másodlagos IP-t amennyit engedett (összesen 3-at). Az RRAS-on ki akartam kapcsolni a DHCP-t nem ment, az opció szürke. Keresgélek, kiderül, hogy ezt valami policy-ból kapja amit a DirectAccess management felületén lehet állítgatni. Ok. Kikapcsolom ott és megadom neki a static poolnak azt a három másodlagos címet.
Kapcsolat próba.
Beengedi a klienst. Hohó béke van. Működik. Lejelentem a főnöknek - lémer :-(
Főnök jelzi, hogy kapcsolódni ugyan tud, de a belső gépeket nem látja.
Próbálok pingelni. A VPN szerver LAN oldali lábáig jutok. Azt még tudom pingelni, tovább semmit.
Feladom. Este 9 nem akarok már ezzel foglalkozni, a dolog amúgy sem volt se fontos se sürgős. Jelzem, hogy ha nem baj másnap folytatnám.
Második nap:
Elkezdek Netmont telepíteni a kliensre is a szerverre is. Rájövök, hogy tulajdonképpen nem kötelező nekem a static poolt ugyanarról a hálóról osztanom. A routing tábla piszkálásával (az amazon routing táblájáról beszélek) oda tudom irányítani a forgalmat, nem kell hozzá a másodlagos IP címes dolog.
Megcsinálom így. Nem megy.
A kolléga mondja, hogy neki van erre egy ötlete. Állít valamit a szerveren. Változás nincs.
Elkezdem nézni az egészet a NetMonnal. Kiderül, hogy a kliensről a csomag szépen elmegy a LAN-on lévő szerverig, majd onnan vissza is jön és a VPN szervernél eltűnik a levegőben. Ez egyértelműen az RRAS körüli routing hibára utal, hiszen az Amazonon minden irányban keresztül mentek a csomagok.
Kínomban próbálok RDP-vel is kapcsolódni, hátha csak az ICMP-vel van baja. Valami "bad checksum" üzenetek vannak a NetMonban. Ennek nem tulajdonítok különösebb jelentőséget, elvégre még a ping sem megy.
További kemény guglizás. Semmi értelmes. Valahol azt olvasom, hogy az off-lan IP tartományhoz fel kell venni egy címet a hálókártyára másodlagos címet. Felveszem, nincs változás.
Elkezdek a technetklub fórumon kérdezősködni. Semmi értelmes válasz.
Feladom. Más munkám is van.
A főnököm kérdezi, hogy mi ezzel a helyzet. Mondom, hogy még mindíg nem megy és a CRM költségkalkulációt csinálom. Válasz: Jó, a CRM fontosabb. Huhh.
Második nap (este):
Újra nekiugrok. Elkezdek felúzni egy második VPN szervert. Próbálnék összehozni egy kéthálókártyás konfigot (RRAS standard verzió, hátha a NAT-os dologgal van baja). Ez sehogy sem megy. Ha kirakom a netre akkor nem tudom belógatni a VPC-be. Ha a VPC-be rakom akkormeg nem tudok neki közvetlenül internetes címet adni, csak NAT-on kersztül. Végülis felhúzok valamit, amiről kb. a második újraindítás után kiderül, hogy nem tudom többé elérni (RDP only mizéria). Lezúzom.
Újrakezdem az egészet. Marad az egy hálókártya. Próbáljunk meg egy tiszta állapotot, hátha a DirectAccess-es konfig a gond. Mire odajutok, hogy a gép felrakja a security fixeket, nagyon késő van. Másnap folyt köv.
Harmadik nap:
Befejezem a második VPN gép konfigurációját. Csak az RRAS, nincs DirectAccess. A helyzet ugyanaz. Sőtt még rosszabb. Itt még vissza sem jönnek a csomagok a LANon  lévő belső szervertől.
Nézem jobbra, nézem balra, semmi. Örjöngök. Két percre vagyok tőle, hogy lezúzzam az egészet és felrakjak egy linuxos PPTP-t.
Szólok a kollégának, hogy nézze meg. A két VPN szerveren ugyanaz van beállítva, ugyanúgy van a routing összerakva. Az egyiknél visszajönnek a csoamgok a LANos gépektől, a másiknál nem. Nézi-nézi, majd eszébe jut valami. Most derül ki, hogy mit állított az előző napon.


Itt kérem security van. A rendszer ellenőrzi, hogy a bejövő és a kimenő IP forgalom megfelel-e a konfiguráltnak. Ezt ki is lehet kapcsolni. Itt ki is kell az off-lan tartomány miatt.
Hurrá. Mostmár mindkét VPN szerveren visszajönnek a csomagok a LAN-ról.
Mit oldott ez meg? Kb. semmit. Ettől még nem megy a VPN.
Feladom. Dél van, el kell mennem elintézni valamit.
Visszajövök és elkezdek AD FS-el, O365-el, Exchange és CRM migrációval foglalkozni. Ezek messze fontosabbak.
Kicsit később még bevillan valami. Mi van akkor, ha annak a NetMonban látott "bad checksumnak" mégis van jelentősége.
Gugli.
Látok olyan bejegyzéseket, hogy más is tapasztalt ilyesmit az Amazon EC2-ben, de azok átmeneti jelenségek voltak és hardver hibára utalnak. Emlegetnek még holmi checksum offload-ot, meg a hálókártya beállítgatásait. Nézzük meg, fájni nem fáj. Irány a Device Manager.


Nézd már, itt van egy olyan beállítás, hogy "Correct TCP/UDP Checksum Value". Ezek tudnak valamit. Ezek szerint el szokott romlani amit javítani kell. Kapcsoljuk be!
És minden elkezd működni.
Épp a Microsoft/Citrix/Amazon jó édes nénikéjét szidom felváltva. Azt, hogy melyik a tettes nem tudom, de ez egy csúnya nagy BUG (jó-jó tudom: feature).

2013. augusztus 31., szombat

Amazon Elastic Cloud - első benyomások

Mostanában elég sokat piszkálom a fenn nevezett cuccot. Egyenlőre nem vagyunk barátok.
Első benyomások:
+ Egyre inkább tetszik a koncepció, hogy pár dolláros óradíjjért akkora vasat gyárthatok magamnak amekkorát akarok. Tesztkörnyezethez piszok jó megoldás
- A felület kicsit kripli, egy rakás dolgot csak idiótán lehet megoldani. A virtualizációs környezetekhez képest fordított logikával
- Összerakott kész gépen nem lehet a belső hálózatos IP címet lecserélni. Hozzáadni lehet pluszban, belül lehet állítani, de az eredetileg amazon által allokált cím az marad
- Nincs gép konzol. Ez a windowsnál igen jó ötlet. Ha elírod az IP címet és nem tudod mi volt a hibás bejegyzés, ha elszúrod az RDP konfigot, ha a gép valamiért nem bootol, stb. Esélyed sincs, hogy rendbe szedd, de még arról se lesz infód, hogy mi a baja (vártam másfél órát egy w2k8 startra, mert frissítéseket konfigurált és nem láttam belőle semmit, azt hittem már megdöglött, pedig nem)
- Van snapshot, de a VSS-ről azt se tudják, hogy mi az. A konzisztens snapshot folyamat szerintük: lecsatolod a gépről a kötetet a gépről menet közben, megcsinálod a snapshotot, majd visszacsatolod. Lécci, csináld meg ezt egyszer egy éles Exchange store alatt!!! :-)

Na egyenlőre ennyi, de még barátkozunk.