Puncte:0

Cum ar trebui să fie create acțiunile FSx pentru unitățile SQL Server pe EC2?

drapel in

Suntem în proces de planificare a migrării întregii noastre platforme în AWS. Gândirea actuală este că ne vom găzdui instanțe pe EC2 și vom folosi FSx ca sistem de fișiere. Totuși, nu găsesc orice despre dacă este recomandată o instanță FSx separată pentru fiecare unitate necesară SQL Server. Este o practică bună să împărțiți fișierele de date, fișierele jurnal și tempdb pe diferite unități pentru a minimiza disputa, dar chiar nu sunt clar cum se gestionează cel mai bine această împărțire cu FSx. Am văzut stocarea instanței EC2 recomandată pentru tempdb, dar ar trebui să folosesc o partajare diferită de o instanță FSx „centrală” sau este cea mai bună instanță discretă pentru fiecare unitate.

Extensia la aceasta este dacă o singură instanță FSx mare pentru toate instanțele EC2 este în regulă sau este cel mai bine să folosiți un FSx discret pentru fiecare EC2? Mă aștept că toate acestea se vor prăbuși pe stâncile costurilor, dar mă străduiesc să-mi înțeleg capul.

Puncte:0
drapel gp
Tim

V-ați gândit să utilizați AWS RDS în loc de EC2 / FSx? În cloud, în general, cel mai bine este să utilizați serviciile acolo unde sunt disponibile, cu excepția cazului în care nu pot face ceea ce aveți nevoie.

Nu cred că trebuie să vă împărțiți între sistemele de fișiere FSx pentru performanță, deoarece FSx este un serviciu gestionat mai degrabă decât un dispozitiv / disc. Puteți pune totul într-un singur sistem de fișiere FSx și puteți crește sau reduce performanța. Cu toate acestea, cred că alți factori depășesc probabil acest lucru, așa cum descriu mai jos.

Uitandu-ma la Prețuri FSx plătiți separat stocarea și „capacitatea de transfer”. Din acest motiv, probabil că aș păstra fiecare bază de date pe o instanță FSx separată pentru a reduce dependența de un singur sistem de fișiere, ceea ce poate crește disponibilitatea. Aceasta înseamnă, de asemenea, că bazele de date non-producție pot fi pe instanțe FSx cu performanță mai scăzută.

O altă perspectivă este că, dacă bazele de date nu sunt întotdeauna ocupate în același timp, ar putea fi mai ieftin să aveți o unitate mare și să partajați „capacitatea de transfer” între ele. Cu toate acestea, pentru mine, acest lucru împinge lucrurile într-un mod care crește șansa de nefuncționare. De exemplu, o eroare umană la ștergerea partajului de fișiere ar putea elimina mai multe baze de date, mai degrabă decât una. Probabil că nu aș face acest lucru decât dacă prețul este critic și dacă necesarul fiabil este scăzut.

Dacă doriți să combinați spațiul de stocare, îl puteți prototipa destul de ușor.

BWFC avatar
drapel in
Ne-am gândit la RDS și probabil că ar fi alegerea noastră ca organizație. Cu toate acestea, dintr-un motiv sau altul, avem un sistem de scârțâit extrem de în vârstă și un contract guvernamental (Marea Britanie). Ei au spus că, pentru a face lucrurile rapid, au vrut o abordare „lift and shift” pentru a ne face upgrade și migrați cât mai curând posibil, deci EC2 etc. Odată ce suntem migrați, există opțiunea de a trece la RDS și mai larg Platformă AWS, dar deocamdată este pur și simplu mutată.
Tim avatar
drapel gp
Tim
Ar putea fi cel mai ușor să regăzduiți (ridicați și deplasați). Replatforma poate fi destul de ușoară cu AWS Database Migration Service, l-am folosit recent și a funcționat bine - dar aveam o bază de date destul de simplă, fără proceduri stocate. Puteți utiliza DMS de la local sau EC2, deci indiferent de orice situație. https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/
BWFC avatar
drapel in
Există diferite definiții ale „cel mai ușor” care sunt folosite de diferitele părți implicate, iar partea care plătește facturile spune că cea mai ușoară abordare este să folosești EC2 etc. Există o mulțime de politici literale implicate în acest lucru, așa că sunt extrem de aversivi față de riscuri. . Cred că este destul de stabilit în piatră faptul că RDS a ieșit (deocamdată), dar, personal, sunt complet de acord cu tine în acest sens. Avem niște consultanți AWS disponibili și dacă spun că o faceți altfel, atunci poate că există posibilitatea de a schimba abordarea.
Tim avatar
drapel gp
Tim
Sunt consultant AWS (nu lucrez pentru AWS) lucrez adesea cu guvernul, uneori este mai ușor să faci doar ceea ce vor ei, mai degrabă decât ceea ce au nevoie, apoi să mergi încet mai târziu. Îmi voi modifica ușor răspunsul în jurul FSx, cred că ar trebui să-l încercați.
BWFC avatar
drapel in
Vă mulțumim pentru contribuție @Tim. Chiar dacă de fapt nu mi-ați oferit niciun indiciu despre împărțirea fișierului de bază de date, care este cheia întrebării mele, cu siguranță există ceva de gândit aici. Încep să greșesc în privința abordării instanței FSx pe cluster de server, deoarece asta va reduce cu siguranță riscul de eroare umană. Dacă există o instanță pentru fișierele de date și alta pentru jurnalele, este supusă testării pentru moment. De asemenea, cred că există avantaje în a putea furniza instanțe diferite în scopuri diferite.
Tim avatar
drapel gp
Tim
Nu cred că trebuie să vă împărțiți între sistemele de fișiere FSx pentru performanță, deoarece FSx este un serviciu gestionat mai degrabă decât un dispozitiv / disc.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.