OVH Xenserver Hybrid SoftRaid

[MrChillax]

Dag Tweakers,

Misschien een beetje een domme vraag maar ik begrijp mijn disk setup niet helemaal

Ik probeer op dit moment een XenServer op te zetten waarin een SSD (2x480GB) en HDD(2x2TB) zitten. De SSD's worden bij de aanmaak van XenServer in een Hardware RAID 1 gezet en gebruikt voor de bootup. Ik kan bij de installatie verder niks kiezen voor de HDD dus ik weet niet precies wat daar mee gebeurt. Volgens mij wordt deze ook meteen in een softraid gezet.

Als ik nu in de server naar de disks kijk krijg ik een local storage van 1.73 TB wat ik niet helemaal begrijp. Wat ik graag zou willen is de HDD en SSD van elkaar scheiden en voor elk een local storage aanmaken. De SSD dan wel als boot voor xenserver hebben. Kan iemand mij hier enigszins bij helpen?

code:

[root@ns3593516 yum.repos.d]# parted /dev/sdd print

Model: ATA HGST HUS726020AL (scsi)
Disk /dev/sdd: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  1908GB  1908GB               primary  raid

Information: Don't forget to update /etc/fstab, if necessary.

[root@ns3593516 yum.repos.d]# clear
[root@ns3593516 yum.repos.d]# parted -l

Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  10.7GB  10.7GB  ext3         primary  raid
 2      10.7GB  21.5GB  10.7GB               primary  raid
 3      21.5GB  480GB   459GB                primary  raid



Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sdb: 480GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  10.7GB  10.7GB  ext3         primary  raid
 2      10.7GB  21.5GB  10.7GB               primary  raid
 3      21.5GB  480GB   459GB                primary  raid



Model: ATA HGST HUS726020AL (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  1908GB  1908GB               primary  raid



Model: ATA HGST HUS726020AL (scsi)
Disk /dev/sdd: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  1908GB  1908GB               primary  raid


Error: Unable to open /dev/md0 - unrecognised disk label.

Error: Can't have a partition outside the disk!

Error: Unable to open /dev/md2 - unrecognised disk label.

Error: Unable to open /dev/md3 - unrecognised disk label.

[root@ns3593516 yum.repos.d]# mdadm --examine --scan --verbose
ARRAY /dev/md/0  level=raid1 metadata=1.2 num-devices=2 UUID=493e582c:29c641d1:0fd57782:ab12acf6 name=rescue.ovh.net:0
   devices=/dev/sdc1,/dev/sdd1
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=635492b4:da48d869:a4d2adc2:26fd5302
   devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=bbb95f88:ed6b7aad:a4d2adc2:26fd5302
   devices=/dev/sda2,/dev/sdb2
ARRAY /dev/md3 level=raid1 num-devices=2 UUID=f1cce70e:bf1db5fb:a4d2adc2:26fd5302
   devices=/dev/sda3,/dev/sdb3
[root@ns3593516 yum.repos.d]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/md0
  VG Name               VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb
  PV Size               1.73 TB / not usable 12.00 MB
  Allocatable           yes
  PE Size (KByte)       4096
  Total PE              454802
  Free PE               452241
  Allocated PE          2561
  PV UUID               E35UTM-xWQT-SEhf-CWLc-KVqL-wu5M-98VRUv

[Hero of Time]

De twee soorten schijven zijn ook gescheiden. Lees maar eens goed hoe het er staat. Elke partitie is een raid1 array met z'n net zo grote tegenhanger. Voor je storage zijn dat sdc1 en sdd1, samen goed voor 1,73 TB. Wat is daarmee dan het probleem?

[CAPSLOCK2000]

Eerst even over die 1.73TB. Je bent in een klassieke IT-valkuil gelopen. De IT werkt binair en (dus) vaak met machten van twee. 8, 16, 32, 64, 128, 256, 512, 1024, etc.... Let op, 1000 zit er niet bij, 1024 wél.

1 kilobyte = 1024 bytes
1 megabyte = 1024 kilobyte = 1024*1024 = 1048576

Daar zie je langzaam het probleem ontstaan. In de spreektaal doen we alsof een kilobyte precies 1000 bytes is en een megabyte precies 1.000.000 bytes, maar de computer denkt daar heel anders over. Hoe groter je schijf, hoe groter dit verschil. Als je om 1 megabyte vraagt, en je krijgt 1.000.000 bytes dan zal de computer (terecht) zeggen dat het 0.95 megabyte is.

2TB = 2 * 1024*1024*1024*1024 = 219043332096 bytes.

Ik durf te wedden dat jouw schijven 200000000000 bytes zijn. Voor het menselijke oog is dat een mooi rond getal, maar niet voor de computer. Eigenlijk is dat een beetje oneerlijk, maar iedereen doet het zo.


Voor de duidelijkheid even de hele stack:
hardware -> partitie -> mdadm -> lvm-pv -> lvm-vg -> lvm-lv -> filesystem -> files

Hoe het zit met hardware en partitie weet je geloof ik wel.
Dat mdadm zorgt voor de softraid wist je ook al.
Dan moeten we het nog even over LVM hebben, dat is denk ik nodig om het plaatje compleet te krijgen. LVM is de Logical Volume Manager en een Logical Volume is ongeveer hetzelfde als een partitie. Ik ga even niet in op het hoe of waarom maar LVM geeft extra flexibiliteit.

Je bent er bijna, draai ook nog even de commando's "pvs", "vgs", "lvs" en "mount"
(Physical Volume Show, Volume Group Show, Logical Volume Show).

Ik vermoed dat XenServer direct toegang krijgt tot een hele Volume Group en daar zelf Logical Volumes van mag maken om aan VMs te geven. Ik denk wel dat daar alleen de draaischijven voor beschikbaar zijn, niet de SSD's, bovenstaande commando's zouden dat duidelijk moeten maken.

Volgens mij is er niks aan de hand en is je systeem goed geconfigureerd.

De SSD's gebruiken voor VM's zou echter wel eens lastig kunnen zijn. Dan wil je die SSD's eigenlijk door LVM laten beheren en het lijkt er op dat dat nog niet het geval is. Een bestaand systeem verbouwen om LVM toe te voegen is echter vrij ingewikkeld. Wel mogelijk, maar niet eenvoudig.

[MrChillax]

Hero of Time schreef op donderdag 13 april 2017 @ 22:53:
De twee soorten schijven zijn ook gescheiden. Lees maar eens goed hoe het er staat. Elke partitie is een raid1 array met z'n net zo grote tegenhanger. Voor je storage zijn dat sdc1 en sdd1, samen goed voor 1,73 TB. Wat is daarmee dan het probleem?

Het probleem is dat ik de HDD's en SSD's gescheiden wil houden in XenServer zodat ik per VM kan kiezen wat ik assign.

CAPSLOCK2000 schreef op vrijdag 14 april 2017 @ 10:48:
Eerst even over die 1.73TB. Je bent in een klassieke IT-valkuil gelopen. De IT werkt binair en (dus) vaak met machten van twee. 8, 16, 32, 64, 128, 256, 512, 1024, etc.... Let op, 1000 zit er niet bij, 1024 wél.

1 kilobyte = 1024 bytes
1 megabyte = 1024 kilobyte = 1024*1024 = 1048576

Daar zie je langzaam het probleem ontstaan. In de spreektaal doen we alsof een kilobyte precies 1000 bytes is en een megabyte precies 1.000.000 bytes, maar de computer denkt daar heel anders over. Hoe groter je schijf, hoe groter dit verschil. Als je om 1 megabyte vraagt, en je krijgt 1.000.000 bytes dan zal de computer (terecht) zeggen dat het 0.95 megabyte is.

2TB = 2 * 1024*1024*1024*1024 = 219043332096 bytes.

Ik durf te wedden dat jouw schijven 200000000000 bytes zijn. Voor het menselijke oog is dat een mooi rond getal, maar niet voor de computer. Eigenlijk is dat een beetje oneerlijk, maar iedereen doet het zo.


Voor de duidelijkheid even de hele stack:
hardware -> partitie -> mdadm -> lvm-pv -> lvm-vg -> lvm-lv -> filesystem -> files

Hoe het zit met hardware en partitie weet je geloof ik wel.
Dat mdadm zorgt voor de softraid wist je ook al.
Dan moeten we het nog even over LVM hebben, dat is denk ik nodig om het plaatje compleet te krijgen. LVM is de Logical Volume Manager en een Logical Volume is ongeveer hetzelfde als een partitie. Ik ga even niet in op het hoe of waarom maar LVM geeft extra flexibiliteit.

Je bent er bijna, draai ook nog even de commando's "pvs", "vgs", "lvs" en "mount"
(Physical Volume Show, Volume Group Show, Logical Volume Show).

Ik vermoed dat XenServer direct toegang krijgt tot een hele Volume Group en daar zelf Logical Volumes van mag maken om aan VMs te geven. Ik denk wel dat daar alleen de draaischijven voor beschikbaar zijn, niet de SSD's, bovenstaande commando's zouden dat duidelijk moeten maken.

Volgens mij is er niks aan de hand en is je systeem goed geconfigureerd.

De SSD's gebruiken voor VM's zou echter wel eens lastig kunnen zijn. Dan wil je die SSD's eigenlijk door LVM laten beheren en het lijkt er op dat dat nog niet het geval is. Een bestaand systeem verbouwen om LVM toe te voegen is echter vrij ingewikkeld. Wel mogelijk, maar niet eenvoudig.

Thanks voor al deze info! Ik ga binnenkort weer even aan de slag hiermee. Het is in principe nu nog steeds een machine die niet in productie is, dus het maakt niet veel uit wat ik er mee probeer.
Ik ben er nog niet heel erg diep in gedoken, dit zal ik ook zeker nog wel doen, maar hoe kan een raid-1 voor 2TB en een raid-1 voor 480GB (waar dan wel nog het OS op zit van 20 GB) maar 1,73TB worden?

** EDIT **
Ik zie het nu in denk ik inderdaad. Hij laat die SSD's helemaal achterwege in de "Storage" van Xenserver?

In ieder geval alvast bedankt, zal binnenkort met meer info komen en mijzelf wat meer inlezen.

[ Voor 4% gewijzigd door MrChillax op 15-04-2017 17:10 ]

[MrChillax]

CAPSLOCK2000 schreef op vrijdag 14 april 2017 @ 10:48:
Je bent er bijna, draai ook nog even de commando's "pvs", "vgs", "lvs" en "mount"
(Physical Volume Show, Volume Group Show, Logical Volume Show).

Ik vermoed dat XenServer direct toegang krijgt tot een hele Volume Group en daar zelf Logical Volumes van mag maken om aan VMs te geven. Ik denk wel dat daar alleen de draaischijven voor beschikbaar zijn, niet de SSD's, bovenstaande commando's zouden dat duidelijk moeten maken.

Volgens mij is er niks aan de hand en is je systeem goed geconfigureerd.

De SSD's gebruiken voor VM's zou echter wel eens lastig kunnen zijn. Dan wil je die SSD's eigenlijk door LVM laten beheren en het lijkt er op dat dat nog niet het geval is. Een bestaand systeem verbouwen om LVM toe te voegen is echter vrij ingewikkeld. Wel mogelijk, maar niet eenvoudig.

Hierbij nog de andere commands; het zou dus wel mogelijk zijn de SSD's voor enkele VM's te gebruiken?
Want in principe gebruik ik die schijven nu alleen voor de Bootup, wat ik toch erg zonde zou vinden.
Zou het misschien makkelijker zijn dan om eerst CentOS op te zetten met daarop handmatig xenserver dan?

code:

[root@ns3593516 ~]# pvs
  PV         VG                                                 Fmt  Attr PSize PFree
  /dev/md0   VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb lvm2 a--  1.73T 1.66T
[root@ns3593516 ~]# vgs
  VG                                                 #PV #LV #SN Attr   VSize VFree
  VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb   1   4   0 wz--n- 1.73T 1.66T
[root@ns3593516 ~]# lvs
  LV                                       VG                                                 Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  ISORepository                            VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb -wi-ao 10.00G
  MGT                                      VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb -wi-a-  4.00M
  VHD-e0bad1b9-c50e-4473-b6b1-2ec38cced86c VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb -wi-ao 40.09G
  VHD-ef5101f0-7fd6-4416-a70d-7a8aea175f23 VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb -wi-ao 24.05G
[root@ns3593516 ~]# mount
/dev/md1 on / type ext3 (rw,errors=remount-ro)
/dev/proc on /proc type proc (rw)
/dev/sys on /sys type sysfs (rw)
/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/shm on /dev/shm type tmpfs (rw)
/opt/xensource/packages/iso/XenCenter.iso on /var/xen/xc-install type iso9660 (ro,loop=/dev/loop0)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/mapper/VG_XenStorage--04acaa8b--8f56--c5ca--4522--0d3417fd9bfb-ISORepository on /var/opt/xen/iso_import type ext3 (rw)

[Hero of Time]

Je moet de twee producten goed uit elkaar houden. XenServer wordt aangeboden als een totaalpakket door Citrix. Dit is een minimalistische installatie van CentOS wat op 2 partities van ~4GB staat (een normale en een 'shadow' of backup installatie, soort van snapshot). Althans, dat was zo toen ik 't gebruikte (versie 6).

Dan heb je nog de community versie van Xen. Die vind je in de repo van veel Linux distributies. Dit is in de basis dezelfde Xen als je bij XenServer krijgt, alleen zonder alle extra management mogelijkheden zoals XenCenter, het beheer programma voor je omgeving vergelijkbaar met VMWare ESXi Client.

Ga je zelf CentOS installeren, dan ga je de community versie van Xen gebruiken.

Wil je de ongebruikte ruimte op je SSD kunnen gebruiken met XenServer, dan zal je via de CLI die ruimte moeten geven aan XenServer. Dit is niet zo moeilijk, je moet alleen even zoeken in de documentatie.

[CAPSLOCK2000]

ik ben er nog niet heel erg diep in gedoken, dit zal ik ook zeker nog wel doen, maar hoe kan een raid-1 voor 2TB en een raid-1 voor 480GB (waar dan wel nog het OS op zit van 20 GB) maar 1,73TB worden?


** EDIT **
Ik zie het nu in denk ik inderdaad. Hij laat die SSD's helemaal achterwege in de "Storage" van Xenserver?

Correct, deze groep bevat alleen je draaischijven en door de "afrond"fout heb je 2.000.000.000.000 byte gekregen, wat wordt weergegeven als 1.7TB.

Hierbij nog de andere commands; het zou dus wel mogelijk zijn de SSD's voor enkele VM's te gebruiken?
Want in principe gebruik ik die schijven nu alleen voor de Bootup, wat ik toch erg zonde zou vinden.
Zou het misschien makkelijker zijn dan om eerst CentOS op te zetten met daarop handmatig xenserver dan?

Ok, dat is min of meer wat ik verwachtte, maar niet helemaal, we weten nog niet waar /dev/md2 en /dev/md3 zijn gebleven, ik kan alleen md0 en md1 verklaren.

Met veel geluk zijn die nog ongebruikt en kunnen we ze toevoegen als storage pool. Typisch maak je er dan eerst een LVM volume-group van en geef je die aan Xen, net zoals het met de draaischijven is gedaan.

Heb je zelf toevallig een idee waar die md2 en md3 voor worden gebruikt?

[Hero of Time]

Ik vermoed dat md2 een vorige versie van md1 bevat en md3 de overige ruimte is. Parted zou dat moeten verduidelijken vanwege de grootte.

[CAPSLOCK2000]

md2 bevat inderdaad de rest van die SSDs en lijkt verder nergens gebruikt te worden. Als we op een of andere manier kunnen bevestigen dat die ruimte echt nergens voor gebruikt wordt dan kunnen we md2 aan Xen geven.

[Hero of Time]

Correctie, eerder had ik het twee keer over md2, maar bedoelde dat md3 de rest van de ssd is. Md2 is een kopie/vorige versie van md1.

[MrChillax]

CAPSLOCK2000 schreef op maandag 17 april 2017 @ 11:24:
[...]

Correct, deze groep bevat alleen je draaischijven en door de "afrond"fout heb je 2.000.000.000.000 byte gekregen, wat wordt weergegeven als 1.7TB.


[...]

Ok, dat is min of meer wat ik verwachtte, maar niet helemaal, we weten nog niet waar /dev/md2 en /dev/md3 zijn gebleven, ik kan alleen md0 en md1 verklaren.

Met veel geluk zijn die nog ongebruikt en kunnen we ze toevoegen als storage pool. Typisch maak je er dan eerst een LVM volume-group van en geef je die aan Xen, net zoals het met de draaischijven is gedaan.

Heb je zelf toevallig een idee waar die md2 en md3 voor worden gebruikt?

Hero of Time schreef op woensdag 19 april 2017 @ 13:22:
Correctie, eerder had ik het twee keer over md2, maar bedoelde dat md3 de rest van de ssd is. Md2 is een kopie/vorige versie van md1.

Bedankt voor jullie antwoorden , ik heb geprobeerd XenServer die rest van de SSD te geven maar dit is nog niet gelukt..... Al veel geprobeerd en documentaties gelezen maar helaas. Hebben jullie misschien nog enig idee wat ik anders moet doen?

code:

[root@ns3593516 ~]# pvcreate /dev/md3
  Writing physical volume data to disk "/dev/md3"
  Physical volume "/dev/md3" successfully created
[root@ns3593516 ~]# vgcreate vol_grep1 /dev/md3
  Volume group "vol_grep1" successfully created
[root@ns3593516 ~]# vgdisplay
  --- Volume group ---
  VG Name               vol_grep1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               427.12 GB
  PE Size               4.00 MB
  Total PE              109344
  Alloc PE / Size       0 / 0
  Free  PE / Size       109344 / 427.12 GB
  VG UUID               KXhsHd-FAzV-HTjM-N4q7-CfOc-A20A-E4spO4

  --- Volume group ---
  VG Name               VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                4
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1.73 TB
  PE Size               4.00 MB
  Total PE              454802
  Alloc PE / Size       18981 / 74.14 GB
  Free  PE / Size       435821 / 1.66 TB
  VG UUID               uiErMr-mZ4t-fhiv-O7PP-U0bg-Q69d-Bdqufe

[root@ns3593516 ~]# pvscan
  PV /dev/md3   VG vol_grep1                                            lvm2 [427.12 GB / 427.12 GB free]
  PV /dev/md0   VG VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb   lvm2 [1.73 TB / 1.66 TB free]
  Total: 2 [2.15 TB] / in use: 2 [2.15 TB] / in no VG: 0 [0   ]
[root@ns3593516 ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb/MGT
  VG Name                VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb
  LV UUID                2NMVKV-XOZn-AmFb-3SqT-PPfG-bCKe-MeQZdi
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                4.00 MB
  Current LE             1
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1

  --- Logical volume ---
  LV Name                /dev/VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb/ISORepository
  VG Name                VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb
  LV UUID                yE1uF6-SF0c-m6UN-koA4-joPh-aeFS-vuvg4T
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                10.00 GB
  Current LE             2560
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

  --- Logical volume ---
  LV Name                /dev/VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb/VHD-ef5101f0-7fd6-4416-a70d-7a8aea175f23
  VG Name                VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb
  LV UUID                eDqZ9l-XSdD-2vnC-KJUu-Rf1U-4Oua-nmI2NN
  LV Write Access        read/write
  LV Status              NOT available
  LV Size                24.05 GB
  Current LE             6158
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

  --- Logical volume ---
  LV Name                /dev/VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb/VHD-e0bad1b9-c50e-4473-b6b1-2ec38cced86c
  VG Name                VG_XenStorage-04acaa8b-8f56-c5ca-4522-0d3417fd9bfb
  LV UUID                YVD1Kj-beh8-wCI1-q5GP-e6CU-6hUb-U4LBCz
  LV Write Access        read/write
  LV Status              NOT available
  LV Size                40.09 GB
  Current LE             10262
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

[root@ns3593516 ~]# xe sr-create name-label=XEN-SSD-Storage shared=false device-config:device=/dev/md3 type=lvm content-type=user
Error code: SR_BACKEND_FAILURE_53
Error parameters: , Logical Volume unmount/deactivate error [opterr=errno is 3],
[root@ns3593516 ~]#

[Hero of Time]

Je maakt eerst een PV handmatig aan op md3, om daarna met het de commando nog een keer erheen te verwijzen. Die eerst stap was niet nodig, XenServer doet het lvm deel voor je.

[MrChillax]

Top! Ik dank jullie zeer! Heb de SSD raid in XenServer toegevoegd en ga er wat mee proberen

[MrChillax]

Nog even een snelle vraag, waar jullie misschien nog een snel antwoord op hebben;

Ik heb nu 2 XenServers die niet op hetzelfde "interne" netwerk zitten. Ze zitten wel beiden op 176.31.227.* maar dat is het publieke IP. Nu zou ik graag een intern netwerk tussen de twee Xen hosts willen hebben waar ik dan data via kan versturen. Ik heb al wat rond geklooid met vSwitch maar ik kan de hosts elkaar nog niet laten pingen. Hoe zou ik dit het beste kunnen aanpakken?