Server für kommerzielles Projekt betreiben

R

rubirockt

Guest
Erstmal hallo zusammen,

wie Ihr dem Thema entnehmen könnt, bin ich leider blutiger Anfänger in dem Thema und bei meinen g***le-Recherchen heute auf dieses Forum gestossen. Nachdem ich in der Webmaster-Ecke das Servertechnik-Unterforum jetzt schon ganz gut durchstöbert habe, möchte ich kurz ein dickes Lob für die vielen engagierten Postings aussprechen. Find ich klasse!

eine kurze Einführung in mein Problem:

Im Rahmen eines Gründungsseminars planen wir (3 Ingenieur-Studenten) gerade ein Projekt, dass in erster Linie Webbasiert ist, bzw. "Mobile Clients" bedienen soll. Bei der Erstellung des Business-Plans kommt es in hohem Maße auf eine vernünftige Kostenkalkulation an, natürlich aber auch auf technische Realisierbarkeit, bzw. Details zur Umsetzung des geplanten. Ich muss gleich klarstellen, dass wir alle so gut wie keine Ahnung vom "Betreiben" eines Servers haben. Ich bin allerdings gewillt, mich in das Thema einzuarbeiten - soweit es nötig und sinnvoll für die Projektierung und spätere Umsetzung ist. Für die Einrichtung und den Betrieb sollen dann natürlich Mitarbeiter engagiert werden - IT, Administratoren , etc (also nicht das wie in einem früheren Posting erwähnte http://www.kinderzimmerprovider.de/
wink.gif
)

Kurz und knapp: es geht also in erster Linie um die Planung / Projektierung - und da haben wir leider noch keine Profi's zur Hand.

Das Prinzip:

I) Es soll für den User eine Clientsoftware geben, die über verschiedene Wege (letztendlich natürlich irgendwie über das Internet) mit unserer Datenbank kommuniziert. In erster Linie sollen Daten nach einer Suchanfrage zum Client übermittelt werden, ab und zu aber auch Daten vom Client in die Datenbank gespeist werden.

Dafür habe ich mir gedacht braucht man:
- Einen Server, der die Datenbank hostet
- Einen Server als Schnittstelle, der die Kommunikation zwischen Internet (respektive Client) und Datenbank herstellt
- Eine sinnvolle Internetanbindung
- Firewallfirlefanz, Router, Kabel, etc.

Ist das in etwa so richtig oder habe ich da einen wesentlichen Punkt vergessen / falsch verstanden, etc.?
-> Wie sind die groben Anforderungen für einen Datenbank-Server? Ist soetwas einigermaßen das richtige oder zu klein oder komplett überdimensioniert und doof?
->Was muss der Server für die Schnittstelle können und was kann sowas in etwa kosten?
-> Von T-Systems CompanyConnect gibt es SDSL - Anbindungen, die flexibel von 4MBit bis 34MBit sind - je nachdem welche Leistung man braucht. Macht sowas Sinn? Aber dazu gleich mehr in der Frage zur Datenmenge


II) Redundanz
Es ist geplant, dass das System redundant sein soll. Also quasi Punkt I) mal 2 - mit verschiedenen Standorten und einer Art Kreuz-Verbindung -> Fällt irgendeine Komponente aus, soll sie von der anderen Ersetzt werden. Bsp: Die Datenbank fällt aus. Es ist noch eine Zweite da, die dann von beiden Schnittstellen-Servern erreichbar sein soll.

- Verdoppeln sich die Kosten dann grob gesagt, oder ist das irgendwie ein erheblicher technischer Mehraufwand, der die Kosten überdimensional ansteigen lässt?


III) Traffic
Es ist geplant, dass die Anfrage vom Client in etwa 100 Zeichen lang ist. Die Datenmenge, die Zurückgesendet wird, wir so um die 400-500 Zeichen betragen. Ausserdem bis zu 30kb Bilddaten. Plaintext wären das dann so um die 100 / 500 byte.

- Wie berechnet man daraus die wirklich Datenmenge -> Was fressen dann Protokolle, Prüfsummen, etc. noch? Und wenn die Daten dann weiter an die (oder von der) Datenbank übermittelt werden, bläst sich dann das Ganze nochmal sehr auf (z.B. für SQL mit den Feldnamen verknüpfen, etc.) ?
- Kann ich auf dieser Basis eine Hochrechnung für den resultierenden Traffic machen, oder wie geht man soetwas an?


IV) Hausinterne IT-Struktur
Was braucht man in etwa, um ein Intranet in einem Büro einzurichten? Also abgesehen von den Arbeitsplatzrechnern meine ich? Ich gehe mal von einem Unternehmen in der Größe bis 20 Mann aus, um's mal übersichtlich zu halten.
Auch die 2km Kabel meine ich jetzt konkret nicht sondern eher:

- ein Server? Dazu ein eigener Server für Exchange? oder läuft sowas alles auf einer Kiste? Irgendwelche Racks um Kabel anzuschliessen / die Rechner zu vernetzen? Sind das eher 100¤ Anschaffungen oder 2000¤ Anschaffungen?
smile.gif

-> Das Intranet soll in erster Linie Exchange laufen haben, eine Groupware wie eGroupWare (mit der wir 3 momentan über meinen Websapce arbeiten) oder MS Project haben, Speicherplatz für Gruppenlaufwerke, BugTracking, eMails von aussen Senden und Empfangen, vielleicht VPN ermöglichen, Internetzugriff ermöglichen, etc. -> so ein typisches Firmennetzwerk eben ^-^


V) und letzte

- Wie kalkuliert man die laufenden kosten in etwa? Hauptsächlich Strom, Support vom Hersteller / Reseller und alle zwei Jahre mal Verschleiß? Oder was nimmt man da an?



-> Fall ihr euch von meinen vielen grundlegenden Fragen erschlagen fühlt: Verzeihung
smile.gif
Ihr dürft auch gerne Teile der Fragen beantworten, wenn ihr eine tolle Anregung dazu habt. Auch Verweise auf Seiten, die einem Einsteiger einen guten Überblick über die Materie geben, sind willkommen! Bitte aber keine Kommentare à la "ui du noob, hast ja keine Ahnung, wie willst'n Du nen Server betreiben. Lass lieber die Finger davon und bewirb Dich besser irgendwo als Angestellter " - wobei das hier im Forum sowieso nicht der Ton zu sein scheint
smile.gif


Auch sei nochmal kurz darauf hingewiesen, dass wir 3 die Server dann nicht selbst konfigurieren wollen. Dafür soll es dann Angestellte mit Ahnung geben. Wir müssen einfach Planen.


Vielen, vielen Dank im voraus. Freu mich auf die Antworten!
 
Das sich Dein Projekt sehr umfangreich anhört und vermutlich eine große Dynamik innehat, würde ich dafür plädieren, das Betreiben der Server schlicht auszulagern.

Es macht in Sachen Manpower wirtschaftlich imho keinen Sinn, alles selbst machen zu wollen.

Von SDSL würde ich abraten, sondern die Server gleich in ein richtiges Rechenzentrum mit den üblichen Goodies (redundante Anbindung von Strom und Connectivity, Skalierbarkeit) verbringen.

Welche Hardware passend ist, kann man erst relativ spät sagen, wenn entsprechende load tests gemacht werden. Auch hier würde ich dafür plädieren, deren Operation auszulagern und den Kram zu mieten.
 
Hi mainlink,

danke für Deine Anregungen! Ein paar Tipps davon habe ich in ein paar persönlichen Gesprächen jetzt auch bekommen - beispielsweise das Auslagern der Server zu einem großen Hoster. Ich hab im laufe der nächsten Woche auch nochmal einige Gespräche mit kompetenten Leuten, die mir sicher auch nochmal eine Vorstellung vermitteln.

Das sowas umzusetzen schwierig und anspruchsvoll ist, war mir ja klar. Aber das alleine die Konzeption schon so schwierig ist, hätte ich nicht gedacht
smile.gif


Auf jeden Fall werde ich meine gesammelten Erfahrungen und das was mir so geraten wird hier auch posten. Vielleicht regt das ja auch nochmal zu Kommentaren an
 
QUOTE (rubirockt @ Mo 19.11.2007, 12:25)Das Prinzip:

I) Es soll für den User eine Clientsoftware geben, die über verschiedene Wege (letztendlich natürlich irgendwie über das Internet) mit unserer Datenbank kommuniziert. In erster Linie sollen Daten nach einer Suchanfrage zum Client übermittelt werden, ab und zu aber auch Daten vom Client in die Datenbank gespeist werden.

Dafür habe ich mir gedacht braucht man:
- Einen Server, der die Datenbank hostet
- Einen Server als Schnittstelle, der die Kommunikation zwischen Internet (respektive Client) und Datenbank herstellt
- Eine sinnvolle Internetanbindung
- Firewallfirlefanz, Router, Kabel, etc.

Ist das in etwa so richtig oder habe ich da einen wesentlichen Punkt vergessen / falsch verstanden, etc.?

Im Prinzip ist das zumindest nicht falsch.

Bloß (und deshalb finde ich die meisten gestellten Fragen zum derzeitigen Zeitpunkt als unsinnig): Findet doch erst einmal jemanden, der Euch so eine Software brauchbar entwickelt, die skalierbar auf einer dreischichtigen (Client, Webserver, DbServer) Architektur läuft.

All die gestellten Fragen sind nachrangig, Kleinkram gegenüber diesem Hauptproblem.

Und von der verwendeten Software bzw. dem genutzten Datenbank-Backend hängen dann andere Fragen ab.

Server -> wird bei einem hinreichend großen Provider angemietet. Da gibt es nicht allzuviele, die eine Mehr-Server-Architektur (mit eigenen Switches plus Firewall) anbieten.
Traffic -> lohnt sich kaum, sich darüber Gedanken zu machen. Traffic ist heutzutage teils inklusive, muß teils nachgekauft werden, ist eben so - hängt ansonsten an der Zahl der Nutzer, die im Augenblick noch unbekannt ist.

server-daten läuft auch auf mehreren Servern (und mehreren Prozessen auf dem Webserver), hat eine eigene Firewall plus Switches, ist bei HostEurope gehostet. Aber diese technischen Fragen sind vernachlässigbar gegenüber den Entwicklungsproblemen, die sich bei der Softwarearchitektur stellen und die Personen mit entsprechenden Kenntnissen voraussetzen. Und wenn Du da drei Leute fragst, dann wirst Du vier Antworten kriegen. Die, die Erfahrung mit solchen Systemen haben, dürften mit ihren Systemen beschäftigt sein, die, die noch keine Erfahrung haben, die machen das learning by doing - die Frage ist dann, wie groß der Spielraum für zu zahlendes Lehrgeld ist.
 
Zu dem Office: Ich würde einen ordinären W2K3-Server nehmen, RAID1, 2 oder 4GB RAM, ohne weiteren Firlefanz. Sagen wir: ¤1.000 ohne OS.

Noch zwei Gedanken:
a) Du mußt dem Thema Backup einige Aufmerksamkeit widmen. Während eine kurze Downtime ärgerlich ist, wäre ein Datenverlust richtig böse.

b) Überlege Dir genau, wie redundant das Setup wirklich sein muß. Wäre es eine Katatrophe, wenn der Service zwei Stunden nicht erreichbar wäre? Falls Du wirklich eine nahe 100% liegende Verfügbarkeit forderst, wird es richtig teuer.
 
Der Server gehört meiner Meinung nach ins Rechenzentrum. Dort hast du eine Anbindung von ca. 100 Mbps. Zuhause hast du vielleicht 1Mbps Upstream. Wenn du passend zur Mobile-App noch eine Website machen willst, *muss* das ins Rechenzentrum da 1Mbps nirgends hinreichen.

Auch wenns Angebote gibt die mehr als 1 Mbps bieten (SDSL) kosten diese meistens mehr als die Anbindung + Server in einem Rechenzentrum.

jAuer hat auch recht, wenn er sagt dass ein Server, die Kabel, etc. das geringste Problem sind. Ich denke aber nicht, dass man die Aufgabe auf mehrere Server verteilen muss. Immerhin sind die Anforderungen für Server welche nur Mobiltelefone bedienen relativ gering (sehr kleine Datenmengen, etc.). Wenn man eine Website macht und darauf 100 Bilder dargestellt sind werden während des Aufrufs vielleicht 50 DB-Abfragen abgesetzt und ca. 120 HTTP-Requests gemacht. Während bei eine Mobile-App wird meistens nur 1 HTTP-Request gemacht und 1-2 DB-Abfragen welche per XML o.Ä zurückgeliefert werden. Das Auslagern des DB-Servers würde sich meiner Meinung nach nicht lohnen.
 
Hi Leute,

erstmal Danke für die Antworten, langsam entwickelt sich das Thema doch noch
smile.gif



@mainlink:
Ein Admin hat mir den Tipp gegeben, als Server-Betriebssystemlösung MS Small Business Server zu verwenden. Ich hab mir das eben mal auf Wikipedia durchgelesen. In der R2 Premium-Version klingt das garnicht so doof. Da bekommt man für ein paar hundert Euro 'nen Exchange/Outlook-Server, SQL-Server, etc. Geht bis max. 75 User, wobei 5 inklusive sind. Ich hab mal eben aus Neugierde einen einigermaßen brauchbaren Server online konfiguriert und bin da mit einer Backup-Lösung, 2GHz Quadcore, 4 GB RAM, etc. und dem Small Business Server Premium auf ca. 3.000¤ gekommen. Wenn das im großen und ganzen serverseitig alles ist, find ich das fair und akzeptabel.

Zum Backup des DB-Servers:
Ja, Backup ist auf jeden Fall unerlässlich. Das habe ich in meiner ersten Version nicht bedacht. Wobei ich eigentlich der Meinung war , dass durch die Redundanz der DB-Server das Backup-Thema erschlagen wäre. Inzwischen überlege ich mir allerdings ernsthaft, ob diese Redundanz so zwingend ist. Wenn man einigermaßen vernünftig back-upt (sagt man da so?
smile.gif
) und die nötigsten einfachen Komponenten doppelt hat (Netzteil auf Halde, etc.), muss halt der Techniker Fersengeld geben und hinspurten. Das sollte gehen. Die wohl meist beanspruchten Teile, nämlich die Festplatten, sind ja durch's RAID kurzfristig eh relativ sicher, oder?

Natürlich wäre es toll, wenn der Service durch Redundanz nahezu ausfallsicher wäre, aber anfangs muss es wirklich nicht übertrieben werden. Wenn (falls..) dann mal ausreichend Geld und Kunden da sind, kann man das ja nochmal übedenken.

@Joel:

Ja, den Tipp mit dem Rechenzentrum hab ich inzwischen auch schon von anderer Seite bekommen. Gefällt mir eigentlich garnicht schlecht. Warum nicht auf vorhandene Kompetenz zurückgreifen? ich denke, recht viel billiger bekommt man es selbst auch nicht hin. Zumal ein Hoster gewisse Risiken wie Stromausfall, etc. sicher besser abfangen kann als wenn man die server selbst betreibt. Auch die Netzanbindung macht dort wohl mehr Sinn. Über eine Terminalverbindung kann man ja (fast ) so gut drauf zugreifen, als ob er neben einem stehen würde, oder?

Und du denkst, die Datenbank sollte auf dem gleichen Rechner laufen, wie die Schnittstellenapplikation? Bis auf einen Kostenvorteil, was spricht hier noch dafür? Und was spricht dagegen, bzw. ab welchem Punkt wird das brenzlig oder unsinnig? Hat das dann was mit der Menge der Anfragen zu tun, oder der verarbeiteten Datenmengen?

Thema Backup: Würdet Ihr auf Band sichern oder auf Festplatten? Mir kommt, nach dem was ich gesehen habe, die Festplattenlösung einfach günstiger vor. Band-Backupsysteme mit einigermaßen Kapazität kosten ja gleich ein Vermögen.. (zumindest dort, wo ich vorhin online konfiguriert habe..)

@jAuer:

Ja, im Prinzip leuchtet das ein. Qualitativ hochwertige Aussagen kann man wahrscheinlich tatsächlich erst treffen, wenn man die fertige Applikation hat. Da wir das allerdings wohl nicht selbst bewältigen können, brauchen wir da in erster Linie mal Geld dazu
smile.gif
Das bekommen wir vielleicht, wenn wir einen Business Plan erstellen, der neben der Aussage wie wir mit der Sache Geld verdienen wollen, auch eine realistische Hochrechnung der Kosten für das erste Jahr, respektive der ersten beiden Jahre beinhaltet. Da beisst sich der Fuchs irgendwie in den eigenen Schwanz finde ich. Ich hab mal eine vorsichtige Anfrage nach einer Kostenkalkulation an eine IT-Consulting Firma gestellt. Die Antwort war schlicht: "sehr geehrter Herr .., leider müssen wir Ihnen mitteilen, dass wir unsere Dienste ausschliesslich Firmenkunden zur Verfügung stellen." -> Jupp, danke auch. Derweil hab ich ihm auch geschildert, dass wir versuchen das Projekt tatsächlich zu realisieren. Naja, vielleicht war ich da einfach zu blauäugig..

Auf jeden Fall hab ich mir gestern mal J2ME und Netbeans mit Web Kit angeschaut. Ich könnte es wohl nicht selbst machen, aber nachdem im wesentlichen alle Funktionalitäten implementiert sind die wir brauchen, denke ich dass die Applikation ganz gut umsetzbar ist. Wir erfinden ja kein Rad neu. Ein Programmierer, der sich im mobilen Sektor schon etwas bewegt hat, könnte das wohl in einem realistischen Zeitrahmen (vielleicht ein halbes Jahr) recht gut hinbekommen.


Danke nochmal für eure Posts! Auch die Kritischen. Sowas regt immer gut zum denken an und hilft mir, die Sache von weiteren Seiten zu beleuchten. Am Dienstag quatsch ich nochmal mit einem Admin zum Thema Hardware. Das wird sicher auch nochmal recht gut. Falls euch noch was einfällt - immer her damit
smile.gif
Und schönen Sonntag noch!
 
Zum Stichwort Backup:

Auch das erledigt heutzutage ein Hoster.

Bei Hosteurope sind alle Server mit zwei Netzwerkkarten ausgestattet. Die eine geht zum Switch / ins Web, die andere geht auf ein eigenes Netzwerk zur Sicherung. Innerhalb von server-daten werden einfach diverse Konfigurationsdateien in ein Verzeichnis kopiert und die Kundendatenbanken einmal gegen 23:30 gesichert. Es gibt dann einen externen Dienst, der sich zwischen 00:00 und 01:00 über die andere Netzwerkkarte alles holt, was ab einem vordefinierten Verzeichnis zu finden ist. Die Daten werden zwanzig Tage lang aufbewahrt, so daß immer die letzten zwanzig Versionen zur Verfügung stehen.

Da konfiguriert man einmalig ein paar Sachen, ansonsten läuft das automatisiert durch. Ich weiß noch nicht einmal, was Hosteurope da für Techniken nutzt - interessiert auch nicht.

Welches Betriebssystem sinnvoll ist, hängt von der Applikation ab. Ein Exchange/Outlook-Server hat nichts mit dieser Webanwendung zu tun. Im Zweifelsfall fragt man beim Vertrieb nach. Ich habe bsp. MS-SqlServer 2005 - Lizenzen bei Hosteurope angemietet. Offiziell findet man nichts auf der Website dazu, mieten kann man die trotzdem. Ich habe allerdings auch keine Ahnung, ob das für J2ME und Netbeans mit Web Kit das richtige Backend ist - für eine .NET-Anwendung ist das sinnvoll.

Bei einem Ein-Prozessor-Server bedeutet Webanwendung + DbServer auf einer Maschine, daß unter Belastung ständig zwischen den Threads geswitcht werden muß und dadurch zusätzlicher Overhead entsteht. Bei Mehr-Prozessor-Maschinen oder bei der Verteilung auf zwei Server ist die Reaktionszeit zwar prinzipiell 'etwas langsamer', da die Reaktionszeit über das interne Netz dazukommt. Allerdings kann bsp. der DbServer ordentlich mit Arbeitsspeicher ausgestattet werden - und hält nun alle Daten im Speicher, muß also nicht switchen. Richtig reizvoll wird so eine Architektur dann, wenn man um einen - sehr mächtigen - DbServer (16 GB Hauptspeicher o.ä.) mehrere Webserver gruppiert werden und die Sessionverwaltung auch in einem eigenen Prozeß (oder auf einem eigenen Server) läuft. Läuft das System ständig unter Last, können einfach zwei oder drei Webserver hinzugefügt werden, so daß sich die Last entsprechend verteilt.
 
Dein Einwand zum Thema Backup ist sehr interessant. Ich hab das in München im Klinikum Großhadern gesehen, dass die Daten des Klinikums automatisch jede Nacht gesichert werden. Ich wusste nicht, dass Hoster die Ihre Leistung vermieten, das Pauschal für alle User auch so machen. Klingt aber eigentlich logisch und sinnvoll. Damit hätte man ja ein Problem schonmal ganz gut erschlagen. Wenn man dann einfach von Zeit zu Zeit die gesicherten Daten auf ein externes Laufwerk auslagert, ist man ja eigentlich datentechnisch relativ sicher, oder?

Wegen dem oben angesprochenen Server / Betriebssystem: Das war glaub ich ein Missverständnis. Ich hatte den MS Small Business Server als Server für das "Interne Firmennetz" angedacht. Die SQL-Datenbank deshalb, weil wir eine GroupWare-Lösung nutzen möchten und die ja meistens auf Datenbanken zurückgreifen.
Für das Betriebssystem und die Applikationen auf dem WebServer hab ich noch kein genaues Konzept - und auch noch zu wenig Ahnung. Aber das mit den gemieteten SQL-Lizenzen klingt nicht verkehrt!

Wie verhält sich das Thread-Problem bei Mehrkern-Prozessoren? Wenn ich zum Beispiel einen Server mit einem Quad-Core - Prozessor ausstatte? Eigentlich müsste das doch die optimale Lösung sein - ich habe alle Ressourcen "nah" beieinander (keine Kommunikation zwischen verschiedenen Rechnern) und trotzdem die Möglichkeit, verschiedene Threads gleichzeitig zu bearbeiten, oder? Und dann gibt es ja noch die Möglichkeit, 2 Mehrkern-Prozessoren in einen Rechner zu stecken, oder? Wäre es so sinnvoll, die Datenbank und die Kommunikationsapplikation auf einem Server laufen zu lassen?

Zum Thema DB-Abfragen:
1 HTTP-Request wird wohl stimmen. Allerdings denke ich, dass für eine Antwort bei uns 5-10 DB-Anfragen nötig sind. Datenmenge hin wie erwähnt vielleicht 500byte, Datenmenge zurück dann in etwa 30kb.
Wenn man als Grundlage jetzt mal 1000 Anfragen die Stunde rechnet (also so alle 3 Sekunden eine Anfrage) - nur mal so als Hausnummer - würde dann ein Server wie gerade beschrieben ins Schwitzen kommen? Für mich klingt es so, als ob das ganz gut zu bewältigen ist.. Und kann man so in etwa einen Richtwert geben, ab wann es für einen Server eng wird? Ab 1 Anfrage pro Sekunde? Oder ganz anders? Oder so garnicht zu sagen?

Wie immer vielen Dank
smile.gif
 
Plattformrechner
Auch wenn hier vieles auseinandergenommen wird, ich kann hier nur zu einem Managed Server raten, event. 1 Cluster, viele unterschätzen, was alleine ein heutiger "Homecomputer" schon an Leistung hinbringt, einen Quadcore für eine Mobile-Applikation halte ich für absolut übertrieben, vor allem, wenn sie in den Kinderschuhen steckt. Ich würde dafür nicht mehr als 200-300¤ / Monat ausgeben am Anfang (Warum für etwas zahlen, dass man nicht benötigt?).

Alles in allem:
1-2 Managed Server mit Raid 1 (1x Backupserver oder Backupspace 1x Webserver)
Betriebsystem ist in der Regel dabei
Jede Woche ein Fullbackup runterladen auf Tape oder so, kann als optimal angesehen werden

Ausbauen kann man immer und schnell, ich würde aber auf keinen Fall bereits von Anfang an in etwas investieren, dass nach 12 Monaten alt ist (die Serverhardware ändert sich extrem schnell).

Datenbankserver:
Also für mich klingt das nicht nach einem "extrem" rechenintensiven Script. Für die Datenbankabfragen würde sogar noch ein Pentium 1 reichen, aber lassen wir das
wink.gif
. Nur so zum Vergleich, meine alten Hostingserver (AMD x2 4200+ 2 GB Ram) haben im ø neben den 10k-1000k httpd Anfragen pro Stunde, etc. 325790 Abfragen pro Stunde auf 24h 7 Tage die Woche und einen Load von 1-3 in der Regel.

Intranetrechner
Die Frage ist immer was der Rechner tun soll, ich kenne 20-Mann Firmen, die haben einen Pentium 3 mit 256 MB Ram am laufen und es reicht. Diese Frage lässt sich so einfach nicht beantworten, ich würde es auf einem vorhandenen Homerechner aufsetzen und einfach einmal testen.
 
Hi Marc,

hab auf dein Posting hin gerade ein wenig über Managed Server gelesen. Klingt garnicht schlecht prinzipiell. Wie verhält sich das im Laufe der Zeit? Werden "betagte" Kisten dann ausgetauscht gegen etwas neueres? Klingt für mich nach so einer Art Leasing-Vertrag?

Du hast auf jeden Fall recht damit, dass man nicht übertreiben braucht - gerade am Anfang. Selbst wenn man das Geld hätte... Aber ich beginne langsam, so eine Vorstellung der benötigten Dimensionen zu bekommen.

Und zum Thema Rechenintensiv: Nein, wahrscheinlich hält es sich in Grenzen.. Aber wie Du wohl schon gelesen hast, tu ich mir da etwas schwer, das zu beurteilen. Auf jeden Fall steht zwischen der Client-Applikation und der Datenbank noch eine Suchlogik, die diverses berücksichtigen soll. Ich weis nicht, in wiefern dass dann eben wahnsinnig Rechenintensiv ist - aber ich könnte mir vorstellen, dass Suchen unter Berücksichtigung und Bewertung diverser Kriterien doch etwas aufwändig ist? (Deshalb hatte ich übrigens an einen Mehrkernprozessor gedacht: Anfrage erhalten -> Kriterien aus der Datenbank lesen -> Bewerten durch Suchalgorithmus -> Entsprechende Daten aus der Datenbank holen -> Zusammenstellen -> rausschicken. So in etwa müsste das doch laufen? Wenn das zusammen mit der Datenbank dann noch auf dem gleichen Rechner liegt, ist vielleicht ein Mehrkern garnicht schlecht? Oder immernoch überdimensioniert?)

Wenn Du mir noch ganz kurz erklärst, wass "ein Load zwischen 1-3" ist?
smile.gif


Zum Intranet: Nachdem hier die laufenden Kosten nicht so wahnsinnig hoch sind (denke ich), sondern eher eine "einmalige" Investition, würde ich jetzt hier aber auch nicht zu tief stapeln. Aber auch hier stimmt natürlich Dein Einwand: "Warum für etwas zahlen, dass man nicht benötigt?". Da lässt sich sicherlich ein guter kompromiss für bezahlbares Geld finden. Ich schätze mal ein Admin frisst eh wesentlich mehr Geld auf als der Server (Intern) an und für sich
smile.gif
 
QUOTE hab auf dein Posting hin gerade ein wenig über Managed Server gelesen. Klingt garnicht schlecht prinzipiell. Wie verhält sich das im Laufe der Zeit? Werden "betagte" Kisten dann ausgetauscht gegen etwas neueres? Klingt für mich nach so einer Art Leasing-Vertrag?


Kannst du selbst wählen, hast du einen 1 Monatsvertrag (fast die Regel heute), so kann man das eigentlich bei jedem Anbieter durch neue Hardware ersetzen lassen.


QUOTE Du hast auf jeden Fall recht damit, dass man nicht übertreiben braucht - gerade am Anfang. Selbst wenn man das Geld hätte... Aber ich beginne langsam, so eine Vorstellung der benötigten Dimensionen zu bekommen.


Hier machen hald viele den Fehler, ich habe mein Unternehmen übrigens mit weniger als 1000 CHF aufgebaut, wobei es nicht so geplant war, dass daraus mal etwas grösseres wird (Jahresumsatz verteilt auf 2 Unternehmen liegt in diesem Jahr bereits über 100000 bei über 1000 Neukunden und dürfte in den nächsten Jahren beträchtlich wachsen, wenn es so weitergeht).


QUOTE Auf jeden Fall steht zwischen der Client-Applikation und der Datenbank noch eine Suchlogik, die diverses berücksichtigen soll.


Deinen Rechner nehmen, Script installieren, Scriptfehler generieren, paar Tausend Anfragen durchlassen (z.B. Load messen), e voilà hast du das Ergebnis als Vergleich. Nun Kalkulieren und du weist welchen Server du benötigst, ein Server ist nicht anderst als ein Homerechner im Bezug auf die Leistung (von der Reduanz abgesehen).


QUOTE So in etwa müsste das doch laufen? Wenn das zusammen mit der Datenbank dann noch auf dem gleichen Rechner liegt, ist vielleicht ein Mehrkern garnicht schlecht? Oder immernoch überdimensioniert?)


Ausprobieren, kannst dir ja einen Managed für 50¤ zutun mit 1 Monatsvertrag und ein Worst-Case nachspielen. Ich denke kaum, dass du einen Managed ohne Mehrkern findest, also ich würde darauf nicht verzichten, z.B. wenn ein Prozess verrückt spielt, kann das sehr nützlich sein (Ein Prozess kann nämlich nicht auf 2 Kernen laufen).


QUOTE Wenn Du mir noch ganz kurz erklärst, wass "ein Load zwischen 1-3" ist?

http://de.wikipedia.org/wiki/Load


QUOTE Zum Intranet

Normalen Büroserver nehmen, gibts für ca. 500-1000¤ bei Dell (Konfiguration z.B. PowerEdgeTM T105).
 
Mit einem Managed Server kann man wirklich sehr viele Probleme an Leute auslagern die sich auch täglich und professionell damit beschäftigen, das ist meiner Meinung nach wirklich eine gute Sache.

Die DB am gleichen Server zu haben ist von der Performance, solange nicht zu viel los ist, sicher kein Problem, ist es sauber programmiert läst sich die Datenbank bei zuviel Last auch leicht auslagern.

@ Redundanz und Backup
Eine wichtige Frage ist immer wie kritisch ist ein Datenverlust. Es gibt Anwendungen wie z.B. ebanking bei denen einfach nichts schief gehen darf und dann gibt es Anwendungen bei denen ein verlorener Datensatz halt nicht ganz so tragisch ist. Das wirkt sich im Entwicklungsaufwand schon erheblich aus.

Allgemein würde ich auch darauf tippen das die Einrichtungs- und Wartungskosten beim Server im Vergleich zur Applikationsentwicklung nicht so sehr das Problem ist. Rechenleistung ist auch bei Managed Servern nicht so teuer und sollte nicht der kritische Faktor sein.
 
QUOTE (rubirockt @ Mo 26.11.2007, 15:02)Auf jeden Fall steht zwischen der Client-Applikation und der Datenbank noch eine Suchlogik, die diverses berücksichtigen soll. Ich weis nicht, in wiefern dass dann eben wahnsinnig Rechenintensiv ist - aber ich könnte mir vorstellen, dass Suchen unter Berücksichtigung und Bewertung diverser Kriterien doch etwas aufwändig ist? (Deshalb hatte ich übrigens an einen Mehrkernprozessor gedacht: Anfrage erhalten -> Kriterien aus der Datenbank lesen -> Bewerten durch Suchalgorithmus -> Entsprechende Daten aus der Datenbank holen -> Zusammenstellen -> rausschicken. So in etwa müsste das doch laufen? Wenn das zusammen mit der Datenbank dann noch auf dem gleichen Rechner liegt, ist vielleicht ein Mehrkern garnicht schlecht? Oder immernoch überdimensioniert?)

Im Prinzip erscheint mir alles Spekulation, solange dieser Teil des Algorithmus nicht einigermaßen geklärt ist.

Für gewöhnlich gehört der Suchalgorithmus direkt in eine Datenbank - weil Datenbanken ja gerade darauf spezialisiert sind, schnell Daten zu filtern, zuzuordnen und zu sortieren - unter Verwendung von Indices und ähnlichem.

Über solche Probleme werden umfangreiche Doktorarbeiten geschrieben. Wenn man das direkt selbst programmiert (eigener Sortieralgorithmus o.ä.), dann kann das zu katastrophal schlechten Ergebnissen führen - einfach, weil das so ein komplexes Problem ist.

Und bei Datenbanksystemen oder bei der Frage, wie Einfügeoperationen behandelt werden und ob die Datenbank transaktionssicher sein muß (was bsp. mySql in der Standardversion nicht ist), kann es erhebliche Leistungsunterschiede zwischen verschiedenen Backends geben.

Nur ein Beispiel: server-daten enthält einen Codeteil, der Vorausberechnungen erfordert. Diese benötigten auf dem MS-Sql2000 knapp 30 Minuten zur Berechnung. Auf dem MS-Sql2005 sank diese Zeit auf etwa 6 Minuten - bei derselben Maschine mit zwei Prozessoren. Sprich: Die Entwicklung der Datenbank-Software führt zu einer besseren Erstellung von massiv parallelen Abfrageplänen.

Die eigentlich entscheidende Frage ist dann, wie lange die Antwortzeit ist und wie sich der Server dabei benimmt. Ist diese bsp. unerträglich hoch, weil der Server swapt und ständig Teile der Datenbank nachlädt oder ist sie unerträglich hoch, weil zwar die ganze Datenbank im Speicher ist (also keine Festplattenaktivität bremst), der Prozessor aber mehrere Sekunden unter Volllast läuft, um eine Abfrage zu beantworten? Im ersten Fall würde ein eigener Server und sehr viel mehr Arbeitsspeicher etwas bringen, im zweiten Fall wäre womöglich der Code überarbeitungsbedürftig bzw. man müßte das Backend austauschen (um parallele Abfragepläne nutzen zu können).
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben