Ryzyko związane z serwerem

Wdrażam nową funkcję, która wymaga danych z baz danych na wielu serwerach. Muszę tylko połączyć dane ze wszystkich tych serwerów i posortować je. Dwie przychodzące na myśl opcje to:

1. Użyj połączonych serwerów i napisz proste zapytanie, aby połączyć i posortować dane, które będą uruchamiane z jednego serwera i gromadzić dane z innych.

2. Użyj aplikacji, aby zebrać dane ze wszystkich serwerów i wysłać je z powrotem do SQL Server, aby posortować (nie chcę implementować sortowania w aplikacji).

Nasze serwery działają w aktywnych / aktywnych klastrach w SQL Server 2008 R2. Wszystkie bazy danych mają takie same uprawnienia, jeśli masz dostęp do jednej bazy danych / serwera, masz do nich uprawnienia. Jest to aplikacja publiczna (która wymaga logowania użytkownika).

Jakie ryzyko wiąże się z korzystaniem z połączonych serwerów? Czy są jakieś wady bezpieczeństwa, którymi powinienem się martwić? Czy są jakieś problemy z uruchomieniem połączonych serwerów w aktywnych / aktywnych klastrach? Czy wystąpiłyby jakieś istotne problemy z wydajnością w porównaniu do alternatywy?

Wydaje się, że istnieje ogólny negatywny „szum” na temat połączonych serwerów, ale nie mogę znaleźć niczego konkretnego, co mogłoby skłonić mnie do przypuszczenia, że ​​istnieją tam prawdziwe obawy.

Połączone serwery mogą działać bardzo dobrze, o ile wymyślisz implikacje:

1. Bezpieczeństwo: kluczową kwestią jest to, że jeśli masz połączone serwery, jeśli jeden zostanie naruszony, wszystkie są narażone na znaczne ryzyko. Nawet jeśli masz różne poświadczenia dla każdego użytkownika na różnych serwerach (co uniemożliwiłoby atakującemu dostęp do innych zasobów, gdyby jedyny wektor ataku został wyciekły / odkrył / zgadł poświadczenia), link może skutecznie ominąć to wszystko. Łącze ominie również zabezpieczenia, które ukrywają inne bazy danych przed siecią publiczną, na przykład w sytuacji, gdy jeden lub więcej serwerów nie dostarcza danych do interfejsu publicznego, więc normalnie nie byłby widoczny przez zapory ogniowe w żaden sposób. Możesz pomyśleć „cóż, czy to samo ryzyko nie stanowi problemu z replikacją?” na które odpowiedź brzmi tak, alereplikacja odbywa się między poszczególnymi bazami danych aplikacji, a trasa połączonego serwera mogłaby potencjalnie zagrozić innym bazom danych na tym samym serwerze (serwerach), ponieważ łącze znajduje się na poziomie serwera, a nie na poziomie bazy danych (oczywiście możesz być w stanie zminimalizować to ryzyko poprzez uważną kontrolę dostępu użytkownika prawa, ale musisz o tym pamiętać podczas planowania). Na marginesie na temat bezpieczeństwa: jeśli serwery nie znajdują się w tej samej witrynie, upewnij się, że używasz jakiejś formy VPN do połączenia ich, zamiast udostępniania programu SQL Server w interfejsie publicznym.

2. Przepustowość: jeśli wszystkie serwery są w tym samym DC z ładną, szybką, nieskomunikowaną łącznością między sobą, być może nie będziesz musiał się tym przejmować, ale zachowaj ostrożność przy bardziej odległych połączeniach, szczególnie jeśli użytkownicy będą mogli uruchomić reklamy hoc zapytania różnych odmian. Kompresja na poziomie łącza VPN bardzo pomoże tutaj w przypadku większości zestawów danych, ale należy pamiętać, że będzie to kosztem większego opóźnienia, które może zaostrzyć problem wydajności (patrz poniżej).

3. Wydajność: jeśli po prostu przeciągasz kawałki danych wzdłuż linii, nie jest to ogromny problem (ale rozważ zablokowanie: zobacz mój następny punkt), ale gdy tylko zrobisz coś za pomocą sprzężeń i tak dalej, istnieją ograniczenia narzędzie do planowania zapytań może zoptymalizować żądania. Jeśli konieczne jest wykonanie wielu wyszukiwań indeksu, które utworzą bardzo wolno działające zapytania, jeśli serwery nie będą względem siebie lokalne ze względu na opóźnienia sieciowe (ten sam problem jest zdecydowanie obecny również w przypadku serwerów lokalnych, ale w mniejszym stopniu), i zamiast tego może użyć skanowania indeksu (kompromis wykorzystania przepustowości w celu uzyskania korzyści z opóźnień) zjadania przepustowości, a jeśli trzyma blokady (aby uniknąć problemów z brudnym odczytem itp.), wpłynie to również na inne części aplikacji.

4. Blokowanie / współbieżność: Odejście od serwera zwiększy czas wykonywania zapytań, co zaostrzy problemy z blokowaniem, o których jeszcze nie wiesz, a tym samym znacznie zmniejszy współbieżność i skalowalność aplikacji. Należy zachować szczególną ostrożność, używając regularnych i / lub długo działających zapytań między serwerami, zwracając uwagę na problem z blokowaniem i podając odpowiednie wskazówki dla planistów.

Dopóki masz wystarczające przepisy, aby zarządzać kwestiami bezpieczeństwa i wydajności, nie widziałbym problemu z używaniem połączonych serwerów, chociaż mogą istnieć lepsze / bezpieczniejsze / bardziej niezawodne / łatwiejsze do zabezpieczenia sposoby osiągnięcia tego samego wynik.

Doświadczyłem tego samego negatywnego „szumu”, ale jedynym problemem, z jakim miałem do czynienia w przypadku połączonych serwerów, jest łatwość, z jaką możesz przeciągać duże ilości danych przez sieć. Z punktu widzenia DBA jest to przerażające, jeśli masz osoby niebędące DBA, które mogą to zrobić, nawet jeśli obiecują, że nie będą nadużywać.

W twoim przypadku pisanie własnej aplikacji nie przynosi żadnych korzyści, ponieważ nadal będzie trzeba przenieść dane. Wygląda na to, że masz bardzo prosty model uprawnień, więc w zależności od środowiska warto skonfigurować specjalne uprawnienia, aby łącze nie było używane tam, gdzie nie musi.

Połączone serwery tworzą prawie „magiczny” stan dla programistów. Ale bardzo łatwo może być przytłoczenie sieci jednym zapytaniem, które może zwrócić setki tysięcy rekordów z 5 serwerów w jednym żądaniu, a także można zablokować rekordy na wszystkich 5 serwerach. Nie pozwolę nikomu oprócz doświadczonych DBA pisać zapytania, dopóki nie przeszkolisz 1 lub 2 najlepszych programistów w zakresie niebezpieczeństw blokowania wszystkich baz danych za pomocą jednego zapytania.

Połączone serwery są jak narkotyk, gdy już z nich skorzystasz, nigdy nie wrócisz i nie będziesz się zastanawiać, dlaczego nigdy wcześniej ich nie używałeś. Nigdy nie miałem problemu, ale zawsze byłem ostrożny.